Skip to content
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

[Feature Request] Restore Resource Patches #386

Open
eliyamlevy opened this issue Sep 28, 2023 · 1 comment
Open

[Feature Request] Restore Resource Patches #386

eliyamlevy opened this issue Sep 28, 2023 · 1 comment

Comments

@eliyamlevy
Copy link
Contributor

eliyamlevy commented Sep 28, 2023

Idea

Restore Patches would be an enhancement for the backup restore operator allowing users to configure patches to be applied to the resources being restored to the cluster. The idea came up in a discussion regarding solutions to this issue.

Reasoning

The feature will allow users to do "mutating" migrations, enabling them to fix potential issues that may occur when migrating to different underlying infrastructures/kubernetes distros/hosts. It also gives our support team greater capabilities around modifying backups while also cutting down the amount of work needed by customers when sending backing and forth backup tar files.

User Experience

NOTE: This is a draft proposal and has not been approved, nor is it a design document either.
The restore patches would be either and extension to the restore CRD or have it's own CRD. They would define a resource selection, path to field which would need to be patched, and an action. Users would be able to create a set of patches to be applied upon restoring the resources. Some potential requirements for the patch are:

  • It should not affect the backup file stored in persistant storage to avoid corrupting important backups
  • Should happen in memory
  • Should have robust error handling so the user can make mistakes in the patch without damaging the underlying cluster.
@mallardduck
Copy link
Member

Unless there's a SURE for this, I would say Rancher 2.10 is a better target.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants