Draft of design for image update automation #5
Conversation
docs/design.md
Outdated
| ### Integration | ||
|
|
||
| The automation controller creates these as indicated by information | ||
| from its specificaiton and the repository it looks at; and it consults |
| # Design of image update automation | ||
|
|
||
| There are three parts to the design, that operate independently, and | ||
| in sympathy with one another: |
There was a problem hiding this comment.
Are all these controllers different Reconcile loops running within the same controller-runtime Manager binary, acting on CRDs? Trying to understand the context
docs/design.md
Outdated
|
|
||
| Some tooling comes alongside these parts: | ||
|
|
||
| - the `tk-image` command-line tool lets you create the resource |
There was a problem hiding this comment.
will this evolve into a tk image subcommand once "graduated"? I guess that's what you mean with "extension to the gitops toolkit CLI"
There was a problem hiding this comment.
I'm gesturing at an extension mechanism similar to git, whereby if tk-image is in the $PATH, tk will invoke it to handle the subcommand tk image.
There was a problem hiding this comment.
Sounds good, thanks for the clarification. Might be worthwhile to mention that idea in the doc.
There was a problem hiding this comment.
The toolkit CLI uses <verb> <kind> <name> <args>, I personally don't like the idea of plugins, it would break the current UX. Images should fit nicely into our current design tk create/get/reconcile/delete/suspend/resume image repository|policy same as sources.
There was a problem hiding this comment.
I don't care too much about operating as an extension. The trade-off in the other direction is that all the command-line toolery is centralised in tk, which must be changed every time there's a new type or system.
There was a problem hiding this comment.
The toolkit repo is where everything comes together, we have all the components installers, CRDs and APIs being assembled, tested and released under a single version. Having tk depend and use all the current APIs was a good exercise to deal with breaking changes and interoperability between them, for example tk reconcile kustomization --with-source. If each component comes with it's own CLI, the trade-off would be on the UX side, things like --with-source and other cross-api commands wouldn't be possible.
There was a problem hiding this comment.
If each component comes with it's own CLI, the trade-off would be on the UX side, things like
--with-sourceand other cross-api commands wouldn't be possible.
This isn't really accurate as stated. It's possible, for example, to have things that depend on source-controller types have an option --with-source, without them being part of tk. Assuming there is some layering to the individual components -- e.g., the image stuff here depends on a source-controller type, but nothing in tk depends on the image stuff -- there can be tools that follow the same user interface and don't lose anything by being separate.
But I think you're going for another point, which is something like "putting everything in tk makes it obvious when the APIs are not interoperable". No argument here -- but I'd be careful not to make every piece need every other piece in order to work.
| `UpdateJob` resources for making changes within a git repository. | ||
|
|
||
| The jobs created by the automation controller and the command-line | ||
| tool use `image-update` as the image to run on the git repo. |
There was a problem hiding this comment.
Have you thought about what to package inside of this image to actually swap out the values?
Kustomize? A custom kyaml binary?
There was a problem hiding this comment.
A custom executable that uses kyaml, most likely. I don't think kustomize would be up to it.
There was a problem hiding this comment.
Right, sounds good. Should be doable essentially with more or less the code written in this commit: weaveworks/wksctl@05eaf54
| The job controller runs `UpdateJob` resources, each of which specifies | ||
| an update operation on a git repository. Each run checks out the given | ||
| repo at the specified ref, runs the specified image with the | ||
| arguments, then commits and pushes as specified. |
There was a problem hiding this comment.
I think we could highlight that the source branch/tag can be different to the destination branch. One workflow that I have in mind is:
- fetch manifests from the latest semver tag
- commit/push patch to the staging branch
- GH Action opens a PR from staging into master
- cluster admin merges the PR and create a GH release
- source-controller pulls the new semver tag
- kustomize/helm reconcilers apply the changes on the cluster
Also removes the suggestion of extensions to tk, which was not warmly received.
|
Deprecating this in favour of the design in fluxcd/flux2#107, which is less general, but also involves a lot less figuring things out. |
TBD: how to specify the automation bit.