Skip to content
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

Open
shubham-pampattiwar opened this issue Sep 25, 2024 · 1 comment · May be fixed by #101
Assignees

Comments

@shubham-pampattiwar
Copy link
Member

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.

@mpryc
Copy link
Collaborator

mpryc commented Oct 1, 2024

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 mpryc linked a pull request Oct 14, 2024 that will close this issue
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
Projects
None yet
2 participants