Have the BSL controller continuously update the server status based on the state of the BSLs

[carlisia]

BSL controller behavior:

set server status as ready

• all BSLs are available, AND
• BSL specified as default exists

set server status as partially ready

• multiple BSLs, any one of them is unavailable, but at least one other is available
• multiple BSLs, all available, but no BSL matches the specified default

set server status as waiting

• no BSL, OR
• existing BSLs, all pending

[ashish-amarnath]

@carlisia did #2674 address this?
If it did, can we close this issue?

[carlisia]

No, these are different things.

[codegold79]

I'll work on this issue.

[codegold79]

Assumptions

• In the description, in the last bullet, a pending status is mentioned. However, I cannot find such a BackupStorageLocationPhase. The Pending status will need to be created.
• This issue is about updating the ServerStatusRequest resource based on BSL status.
• The ServerStatusRequest resource is updated by the server status request controller and not the BSL controller, as the title of this issue seems to indicate. This is one reason why the BSL cannot update the SSR continuously per the issue request.
• Continuous updating of the SSR is not necessary. The latest BSL status can be picked up whenever a SSR is newly created.
• SSRs do not have "Ready", "Partially Ready", nor "Waiting" statuses. These will need to be created in server_status_request_types.go.
• The only way to look at the server status using the Velero client is by the velero version command.

Planned Solution

• Within the backup_storage_location_types.go file, add a BackupStorageLocationPhase called Pending. All new BSL objects will have the phase set as Pending and will stay as such until updated by the BSL controller.
• Within the server_status_request_types.go file,
  • add a field Server to the ServerStatusRequestStatus struct
  • the new Server field can have the statuses Ready, Partially Ready, and Waiting.
• Whenever a ServerStatusRequest resource is created by the user, the ServerStatusRequestReconciler will look through the BackupStorageLocation list. The status (Available/Unavailable/Pending) and whether or not a default exists for each BSL can be looked up by SSR controller. SSR controller will update the SSR status server field (Ready/Partially Ready/Waiting) accordingly.
• The output of the new server status details can be triggered by using velero version and I expect it to look something like

  $ velero version
  Client:
       Version: v1.6.1
       Git commit: -
  Server:
      Version: test-1008
      Status: Partially Ready

@zubron and @dsu-igeek, what do you think of my plan above? Given my assumptions, what this issue requests seems awkward to me. Do you have different assumptions or a different plan?

[codegold79]

After getting some good feedback for my initial design proposal at the Oct. 19, 2021 Velero Community meeting, I have created a design doc PR that incorporates many changes that deviate from what is posted in previous comments above.