-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use custom UUID for NAB Object to Velero Backup Object mapping instead of the Kube UUID #89
Labels
Comments
Please note comment: #86 (comment) |
mpryc
added a commit
to mpryc/oadp-non-admin
that referenced
this issue
Oct 14, 2024
With this change a new UUID is generated to reference parent/child relationship between objects in the Non Admin Controller use cases. The first consumer of this UUID is a Velero Backup, created when the NonAdminBackup object is reconciled. The NonAdminBackup object generates the NAC UUID and stores it in its Status. This prevents users from modifying it. The UUID is later used to create the Velero Backup during reconciliation. While the NAC UUID is currently used as the Velero Backup name, this is not required, as the UUID is also stored as a Velero Backup label, which is used during the reconcile loop. Usage of NAC UUID as Velero Backup name is to easy it's creation. This PR also includes small changes to fix linting issues of the code, as well reworks the tests to properly take advantage of gingko BeforeEach function. Signed-off-by: Michal Pryc <[email protected]>
mpryc
added a commit
to mpryc/oadp-non-admin
that referenced
this issue
Oct 14, 2024
With this change a new UUID is generated to reference parent/child relationship between objects in the Non Admin Controller use cases. The first consumer of this UUID is a Velero Backup, created when the NonAdminBackup object is reconciled. The NonAdminBackup object generates the NAC UUID and stores it in its Status. This prevents users from modifying it. The UUID is later used to create the Velero Backup during reconciliation. While the NAC UUID is currently used as the Velero Backup name, this is not required, as the UUID is also stored as a Velero Backup label, which is used during the reconcile loop. Usage of NAC UUID as Velero Backup name is to easy it's creation. This PR also includes small changes to fix linting issues of the code, as well reworks the tests to properly take advantage of gingko BeforeEach function. Signed-off-by: Michal Pryc <[email protected]>
mpryc
added a commit
to mpryc/oadp-non-admin
that referenced
this issue
Oct 14, 2024
With this change a new UUID is generated to reference parent/child relationship between objects in the Non Admin Controller use cases. The first consumer of this UUID is a Velero Backup, created when the NonAdminBackup object is reconciled. The NonAdminBackup object generates the NAC UUID and stores it in its Status. This prevents users from modifying it. The UUID is later used to create the Velero Backup during reconciliation. While the NAC UUID is currently used as the Velero Backup name, this is not required, as the UUID is also stored as a Velero Backup label, which is used during the reconcile loop. Usage of NAC UUID as Velero Backup name is to easy it's creation. This PR also includes small changes to fix linting issues of the code, as well reworks the tests to properly take advantage of gingko BeforeEach function. Signed-off-by: Michal Pryc <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We use Kube generated UUID for establishing mapping between NAB Object and Velero Backup Object. Instead of this, use a custom UUID for establishing mapping. This will help avoid UUID collisions.
The text was updated successfully, but these errors were encountered: