-
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
Inform non admin user how much operations are left before running its request #20
Comments
One suggestion: I believe once the backup/restore starts running (phase is running) we directly remove the Queued condition/phase, so no need of the |
The implementation will contain:
Having the above will allow us to make different 'counters' of where the backup is and what is the queue based on the phases. Currently it makes sense to pass the following phases of the 'queued' backups: |
Question at the bottom. Let's say we have initial NABs: NAB_A (1st out of 4)
NAB_B (2nd out of 4)
NAB_C (3rd out of 4)
----> Someone creates yet another VeleroBackup (can be any, even not non-admin)
NAB_D (5th out of 5) When someone creates NAB_A (1st out of 5)
NAB_B (2nd out of 5)
NAB_C (3rd out of 5)
NAB_D (5th out of 5) The same happens when someone removes If NAB_C (1st out of 3)
---> Remeber there is one VeleroBackup that is created outside of NAC controller, that's why we have 3
NAB_D (3th out of 3) My question here:
|
this can be solved changing message to |
@mpryc I would assume the queue is coming from an I do not think a live queue that auto updates is in scope. Hope this simplifies things :) |
Since Velero does not process backups in parallel (one at a time, in order of creation timestamp), non admin users need information about how much backups (without time estimation) are queued before running the requested NonAdminBackup.
This information can be shown to admin users by running
velero backup get
, but since non admin users do not know about other non admin users backups (and admin user backups), it is important to inform this in status of NonAdminBackup object. This will be done by adding:Same thing applies to restores and NonAdminRestores.
The text was updated successfully, but these errors were encountered: