-
Notifications
You must be signed in to change notification settings - Fork 7
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
Change: use build-deploy-tool for backup schedule generation #125
Conversation
b272acb
to
59e52f9
Compare
54df929
to
47c1194
Compare
I re-deployed one of our test environments in our test cluster that has k8up v1.x and k8up v2.x installed. The build created all the new k8up.io resources and removed the older backup.appuio.ch resources from the namespace. Backups have since completed in this environment and appear in the Lagoon UI and are retrievable. |
This changes quite a bit about how the templates are generated, I've tried to cover off as many of the potential cases with tests that generate the schedules and prebackuppods that were previously using helm. Would be good to get some extra 👀 on this to see that it isn't going to change much else. I've done basic test coverage for the things I could think about, but happy to add more if I'm missing some that I couldn't think of |
799f813
to
1d74c4d
Compare
dd66372
to
1a3516f
Compare
865c4e7
to
6f6dda1
Compare
6f6dda1
to
3198d1a
Compare
This replaces the bash script used for handling backup schedules with the build-deploy-tool command.
Also bundled into this is the creation of
PreBackupPods
rather than via the helm templates. This brings all of the backup related generation to one command.It is currently wrapped in a feature flag wrapper to use, you can set this on an project, or environment, or define it in the
remote-controller
withDEFAULT|FORCE
.The default is to fall back to the previous behavior of checking if k8up v1.x is installed. Eventually v1.x support will go away.