Inform non admin user how much operations are left before running its request

[mateusoliveira43]

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:

• a condition to represent it is queued
• and how many are queued:
  • 0 meaning it is currently running
  • greater than 0 meaning that that amount of backups need to complete before running requested NonAdminBackup.

Same thing applies to restores and NonAdminRestores.

[shubham-pampattiwar]

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 0 backups message.

[mpryc]

The implementation will contain:

• Function which will take:

  • *velerov1api.Backup as an argument
  • list of strings as an argument (valid phases. Phases are valid Velero Backup phases: here)

• Function will return

  • Filtered list of *velerov1api.Backup objects that are within passed Backup phases (or all if not defined) from the same namespace as the *velerov1api.Backup that has been provided as an argument

• Another function will:

  • Count the number of *velerov1api.Backup that are newer then provided *velerov1api.Backup

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:
BackupPhaseNew BackupPhase = "New"
BackupPhaseInProgress BackupPhase = "InProgress"
BackupPhaseFinalizing BackupPhase = "Finalizing"

[mateusoliveira43]

@mpryc we will also need this to Restores, as mentioned in #35. Do you believe this implementation allows to after do the same for Restores?

[mpryc]

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 VeleroBackup we should update all of the NAB_* to be:

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 VeleroBackup or VeleroBackup finishes.

If NAB_A and NAB_B finishes we should end up with:

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:

• Do we really want to have such updates, as this will cause many NAB Status updates on every single VeleroBackup change.

[mateusoliveira43]

this can be solved changing message to X backups ahead ❓ , where X is number of objects that will be processed first

[weshayutin]

@mpryc I would assume the queue is coming from an oc get backups or velero backup get command? Perhaps even a new command. Like any other command the user would have to rerun the command to get any new data correct?
If the user wants a running live queue they can use the watch command.

I do not think a live queue that auto updates is in scope. Hope this simplifies things :)