add: automated upgrade process RFC #36
Conversation
There was a problem hiding this comment.
The process described here makes sense. But isn't this already covered on this RFC https://github.com/giantswarm/rfc/tree/main/automatic-app-upgrades ? Quoting
We could set up rules for Flux controllers to update App CRs in a repository whenever a new chart version (matching the automation rule) is pushed to the Azure Container Registry. Then Flux GitOps controllers would see the update in the repository and apply it to the cluster, effectively updating the App CR with the new version. All of this would be triggered automatically after a new release is crafted for any of the apps. The updated App version would be committed to the branch watched by GitOps controllers so that the update happens automatically.
That sounds basically the same. If this RFC is about explicitly mentioning bases and linking to our gitops repositories, wouldn't it be better to update the other RFC?
gianfranco-l
changed the title
|
yeah @piontec WDYT about integrating with the existing one? |
|
Yeah, makes sense, I need to merge them |
| 1. The new App Chart CR is tested for successful [upgrade using `ats`](https://github.com/giantswarm/app-test-suite#quick-start) | ||
| 1. The App is released, the chart has to be put into OCI repository (already supported by `architect-orb`) | ||
| 1. GitOps configuration part | ||
| 1. Customer has prepared GitOps repository, including bases (they don't have to be bases, they can be individual clusters/apps, but we're encouraging bases for better (re)usability) that make sense for grouping their infrastructure (Honeybadger is working on specific layout recommendations) |
There was a problem hiding this comment.
I think this structure is really the important thing.
|
@MarcelMue @piontec what is holding us back from merging this PR and close this ticket? |
IMO nothing is stopping this PR to be merged but it only addresses some points from the issue. |
No description provided.