Short description
As a SRE I want to update wego/flux k8s cluster so that I'm running the latest code.
Flux does this by downloading new version and reinstalling...
wego upgrade
For now we will only support one previous version when upgrading. A PR will be created in the wego platform repository (assuming only one repository needs to be updated). The cluster/target will be upgraded when the PR is merged.
Discussion
Upgrading a Weave GitOps installation
The process of upgrading Weave GitOps for a single cluster consists of two pieces:
- Upgrading flux controller resources
- Upgrading resources generated by Weave GitOps
Flux Controller Resources
Flux controller resources should not constitute a significant problem since flux supports upgrading them by simply downloading a new flux version and re-installing flux. As we don't expect users to modify the core flux manifests, the only reason we store them at all is so that upgrading can be done via pull request. We'll simply need to run flux install --export
and overwrite the existing flux manifests in the platform repository with the new ones generated by the install.
Resources Generated by Weave GitOps
Resources generated by wego app add
are potentially a bit more complicated in that we expect users may modify them (to change the sync interval, for example). It would be a much better user experience if we were to keep any such changes during the upgrade. According to the flux migration timetable, any breaking changes to the CRDs will come with associated conversion mechanisms. So, we should be able to run/apply such mechanisms during an upgrade when such a change occurs. As of yet, it isn't clear what such mechanisms will look like so we will have to plan to be flexible if/when breaking changes occur. In the absence of such breaking changes, we should be able to leave flux-generated resources alone. The only resource we may have to update is our own app
resource. That should be a relatively straightforward change, though, since the app
resource has no user-serviceable parts.
Pull Requests
An unfortunate side effect of our choice to allow configuration to be stored in multiple places is that we can't always upgrade everything with a single pull request. For flux-only upgrades without breaking changes, we will only need to create a PR for the platform repository. However, if we change the app
resource or a breaking change occurs in the flux CRDs, we'll need to extract the config URL from each app managed by Weave GitOps and create a PR in each referenced repository with the necessary changes. The UI or CLI will have to inform the user of all the repositories that will need PRs reviewed and merged. (It's possible that this issue will be go away if the directory structure changes play out as currently discussed)
Multi-cluster
In a multi-cluster environment there will be applications that are deployed in multiple clusters. The GitOps management resources for the applications (other than the app
resource), however, will be segregated by cluster. So, wego upgrade
should be able to work just fine on an individual cluster. The only place in which that might be problematic is the app
resource, which is shared. This suggests that we'll need to ensure all app
changes are backward-compatible (for some number of releases) so that we can upgrade the app
resources during an upgrade for a single cluster.