Allow resource status restore in a more granular way #8204
Comments
I think it's important to note that the place this indication is made is as important as the granularity. For example (not that this would be a good design) it wouldn't be very helpful to have to provide a label selector on the |
|
@carbonin As far as I understand this, we have no plans to require a label selector on the restore. Rather the idea would be that any resouce with the defined annotation on it would have status restored without the user creating the restore needing to do anything explicit. |
|
Why not set the label on the CustomResourceDefinition. At least in my case I want all resource objects of my CRD to be restored with Status. Of course having labels on the resource objects, would also be fine. |
|
Hi Thomas
We may want to be able to restore the status only for certain resources sharing the same definition. For example only Hosts created in a certain way.
Having the options to tag the CRD I think is also useful.
Nick, your team had required this enhancement , do you have any comments ?
Thank you,
Valentina Birsan
Principal Software Engineer - Advanced Cluster Management for Kubernetes
Red Hat Canada
… On Dec 10, 2024, at 8:38 AM, Thomas Güttler ***@***.***> wrote:
Why not set the label on the CustomResourceDefinition. At least in my case I want all resource objects of my CRD to be restored with Status.
Of course having labels on the resource objects, would also be fine.
—
Reply to this email directly, view it on GitHub <#8204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKIEQZXQD7A5Z3NXCCREGJ32E3VGPAVCNFSM6AAAAABN7OGCFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZRGY3DGNRYGI>.
You are receiving this because you are subscribed to this thread.
|
|
I would prefer something on the CR as opposed to (or in addition to) the CRD because it's more flexible and also because controllers dealing with resources may not have permissions to edit CRDs at runtime. CRD owners may not know anything about whether a resource should be restored with status or even if velero is in use. |
|
BTW: I see a race condition:
How can the author of the controller differentiate between a "restore in progress" and a new applied spec? |
|
BTW: KEP 2527 Status is, effectively, as durable as spec.I think Velero should change the default. The status should be restored, except there is configuration to not do it. |
|
@guettli Even if Velero changed the default, that wouldn't resolve the race condition. As I understand it, we would still have to create the object first (since status is stripped on Create calls), then patch it like we do now. So the only change if we swapped the default would be to replace a whitelist with a blacklist -- functionally, everything else would be equivalent. This would also be a breaking change for Velero, since suddenly restoring status in a new release would change expected restore behavior, likely confusing users. If we wanted to provide a blanket "restore status by default" feature, it would need to be opt-in -- i.e. a new restore spec field which, if |
Yes, this sound like a good idea! |
Velero already support restoring status via the
This sounds like a fine enhancement, but it's not what I was asking for in this one which was specifically to allow whether status is restored or not to be controlled by something on the resource itself. |
Describe the problem/challenge you have
Users don't have the knowledge required to understand the proper use and implications restoring the status of a resource, but the controller managing a resource does.
It would be very useful for the controller of a resource to be able to set some flag (annotation, label, etc) to indicate that the status for that resource should be restored.
Describe the solution you'd like
Currently the only way to handle this is to either instruct users to restore particular resource types in the Restore CR. The only alternative from the controller standpoint is to duplicate status information in an annotation and apply it when an object is restored. This is cumbersome for controllers as they now need to keep duplicate information up to date in the actual status and in the annotation.
Anything else you would like to add:
This feature will provide a more granular way to enable resource status restore. Currently, we can only specify the resource status to be restored at a resource type level, this feature will enable at a particular resource types's instance level.
Environment:
velero version):kubectl version):/etc/os-release):Vote on this issue!
This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.
The text was updated successfully, but these errors were encountered: