Re: [gitops-wg] Improving GitOps usability
toggle quoted messageShow quoted text
Thank you for bringing this to the group. I legit wish I had this when I was working in the Duke Health system. Would've made our lives much easier.
I can see extensive use of this being made in highly regulated environments right off the bat. This is also useful if you want to create safe, happy paths for folks to release their services/code with the downside of if you're not on the happy path you're going to have to go through other approval process(es) of some sort. This has been a practice for a while just never quite this tight (nor this native to Kubernetes).
w/r/t GUIs: By default, I don't think GUIs are necessary for GitOps tooling. If there is an edit source option in the GUI, a request should be made to commit a changeset through normal approval processes, not a direct commit to the source of truth. This can be managed a number of ways but, we should strive to encourage folks to build out tooling in a production-ready manner with appropriate safeguards either in place or documented where needed.
w/r/t writing back to the repo: To be clear, this needs to be safeguarded somehow; drift detection only works if there's something different to compare against. If you're saving your diffs back to the git repo while breaking your environment you'll wish you hadn't when you realize prod is down and there's 17 revisions to rollback through. I urge some caution here and ask folks to remember the rigor needed to approve changes to environments and/or known good configurations. That's where we as a subproject could write something up or reference something so folks can build out their approval processes in a GitOps way to save some headaches (approval processes only work if they're followed).
On Wed, May 25, 2022 at 4:59 AM Stefan Prodan <stefan@...> wrote:
Flux controllers read config from git but can't push changes back.Flux can write back to Git, but only for container image update automation. Flux image-reflector-controller scans container registries to find new versions, then Flux image-automation-controller patches the image tags based on user-defined policies, then commits and pushes the changes to Git. Like kpt v1, Flux uses kyaml setters to patch YAMLs in Git, to preserve comments. Docs here https://fluxcd.io/docs/guides/image-update/