[RFE] Add a cluster metadata mechanism for Backups #612
Description
🚀 Feature Request
This will (hopefully) further solve issues like this: rancher/rancher#47581.
It's not the first one like this we've gotten and even with this change may not be the last.
However, until we try we can't say for sure that BRO itself can't make this more clear.
Background
When using BRO in the context of Rancher (i.e. Rancher Backups) the delineation between performing an "In-place Restore" and "Migration" can be very important. Currently the onus of understanding that is fully on the User interacting with the backups. This person needs to be well read on the Rancher Backups documentation, understand the state of the cluster when each backup point was created, and how that compares to the current cluster they're interacting with.
This is an easily overlooked aspect of how Rancher Backups is intended to operate. As issues around this come up we adjust documentation the best we can. Rather than continue to "patch via docs" we could implement a more foundational solution to serve as an indicator.
Is your feature request related to a problem? Please describe.
Not exactly - more about clarifying a process that has some ambiguity.
Describe the solution you'd like
- BRO team adds a mechanism for Backups to be correlated to the cluster they are created on.
- In turn, that is used to add a status field to the Backup indicating if it's valid for "in-place" restore.
- Finally, the Rancher UI (and CRD list) is updated to add a "In-Place Restore" column to display the status field in the Backups list.
Logically, the UI stuff needs to come last and can be considered a follow up effort. However we may even want/need to split the first two tasks into their own efforts/PRs.
We will need to explore the most effective way to get the results we're logically expecting. Since it's rather easy to dream up a metadata file we add to tars, but then that implies that to know if we can do an in-place we need to read the tar. Which won't scale well.
Technical Implementation
- When backups are created add a new metadata field to contain cluster ID (of some sort),
- Add a status field to the backup CRD based on if that metadata field matches the current cluster,
- If the field is unset, status is unknown; or, false with a status condition might be better?
- Add UI change to display that status field in table.
Describe alternatives you've considered
While I have considered this idea in the past (a few times over the last few months), none of those ideas were viable as functional options nor worth documenting. At the current time, the only other alternative for solving this issue is adding more docs.
Additional context
N/A