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

Add Non-Admin Backup Sync controller #38

Open
shubham-pampattiwar opened this issue Apr 9, 2024 · 8 comments
Open

Add Non-Admin Backup Sync controller #38

shubham-pampattiwar opened this issue Apr 9, 2024 · 8 comments
Assignees

Comments

@shubham-pampattiwar
Copy link
Member

For creation of Non-Admin restore CR, the non-admin user will refer the non-admin backup instance. Most times in disaster recovery scenarios the NS will cease to exist and with it the Non-Admin Backup CRs too. Therefore, it is desirable that once the application NS exists and it does not have the relevant user's non-admin backup CRs, then there should be a mechanism to re-create those in the user NS, so that the non-admin user can view and use them for creation of non-admin restore CR and trigger the restore operation. Ensuring the appropriate sync of Backups would be the primary responsibility of Non-Admin Backup Sync controller.

Another point of note is that, this work would put the infrastructure in place for enabling cross cluster non-admin backup/restore operations in the future.

@weshayutin
Copy link
Contributor

Only terminal state... completed or failed state crs

@weshayutin weshayutin moved this from New / Design to Todo in OADP Apr 9, 2024
@mateusoliveira43
Copy link
Contributor

Example implementation https://github.com/vmware-tanzu/velero/blob/bc29471ed6e94eda2129a7a070080b4f11b420de/pkg/controller/backup_sync_controller.go

should it also have a user time input for how frequent sync?

@mpryc
Copy link
Collaborator

mpryc commented Apr 16, 2024

  1. Find all Velero Backups in the namespace where the controller resides
  2. Check if those were created by NAC controller (labels)
  3. Check if corresponding NABs are in the namespaces
  4. If there is a namespace without corresponding NAB, create NAB, but with a state that won't reconcile main NAC reconcile loop that creates another Velero Backup

The sync should work on:

  • any new namespace creation event on the cluster
  • time based ?

@mateusoliveira43
Copy link
Contributor

just namespace creation event seems problematic

Example: admin user configures new cluster and then installs OADP. All non admin namespace already exist once NAC is live, then sync will not happen, right?

do we also need design for this?

@mpryc
Copy link
Collaborator

mpryc commented Apr 17, 2024

I think the following then would be ok:

  • on any namespace creation event
  • on start of the sync controller (regardless of the namespace creation)

@shawn-hurley
Copy link

What happens when you have a create event that you don't get before an update occurs? You will end up with only an "update event" in the queue

@mpryc
Copy link
Collaborator

mpryc commented Apr 17, 2024

What happens when you have a create event that you don't get before an update occurs? You will end up with only an "update event" in the queue

So the create and update events on the namespace as well?

@shawn-hurley
Copy link

shawn-hurley commented Apr 17, 2024

I am only suggesting that the event types are not to be relied on in any real way because you are not guaranteed to get every single event and to think of them not as "create" or "update" events but "something happened to resource X that I may care about" the goal is to determine the "may care about" based on the state of the cluster IMO.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Todo
Development

No branches or pull requests

5 participants