-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Conversation
My vote goes to a
|
Alright, will do. How about the command line options? Is that acceptable? I think linkerd does a more sophisticated thing, inspecting and exposing all the available chart options, but I think it's a bit overkill. I would rather keep it simple. |
@2opremio the The Helm operator setting the default and a user supplying the argument here will have the desired effect (as Flux takes the value of the last supplied argument), but will not return a pretty YAML, which is probably a requirement. |
Yep, simple for now! On command-line options: those you have are a good base. You can remove Since people can mess around with the output as much as they want, it's not that important to get all the bells and whistles in, or to have an escape for extra args. But looking ahead a bit, I would like to see
as arguments. |
Versioning is tricky isn't it. If you build in whatever's in the files (either the chart or example deployment) at the time of release, that's probably going to have most of the bells and whistles from fluxd in that release -- but it won't correspond to a released chart, which always comes after a fluxd release. If you include the last released chart, in general it won't have arguments for fluxd in the same release. If you try to use the latest chart, fluxctl has to understand, for all supported versions -- which will have to include future versions, since see above -- how to encode the arguments it's given into Helm values. With those points in mind, here's an idea: make the deploy/ examples into very simple text templates, along with all the comments and commented-out bits, and bundle those into the fluxctl binary. Pros:
Cons:
|
How about using Kustomize as a library and use generated-patches to modify the manifests on deploy/* on the fly? This will allow us leave the the manifest files unchanged and save us from maintaining separate templates (or invent an annotation language to maintain the existing templates) EDIT: this won't preserve comments because Kustomize doesn't support it AFAIK |
Or, we can create |
Pros:
Cons:
|
I reckon (either for this or for the kustomize version) just replace it. It doesn't especially serve a purpose other than as a starting point, now -- you can't just apply what's in there, for instance. |
My idea was to apply the patches on the fly and print the patches manifests. |
I did that all the time when developing (after tweaking the git repo). Also, the guides rely on it. |
Right, you had to tweak it, i.e., edit it. You would still be able to do that, especially if it's a kustomize input. |
Ah, but you are saying there is no need for that after |
568ba2f
to
09c421b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would undo the changes to the helm chart and restore the deploy dir. If people use Kustomize they will want the YAMLs in git see #2253
d3922e0
to
c312d79
Compare
Also, fix bin/helm/update_codegen.sh when there is no GOPATH defined
8a55252
to
909b9b0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tidy and clean, thanks Fons 🌷
This could have done with a bit of a rebass before merging :-/ Never mind, done now. |
now that fluxcd/flux#2287 is merged we can use upstream flux
Now that fluxcd/flux#2287 is merged we can use upstream Flux
Now that fluxcd/flux#2287 is merged we can use upstream Flux
* Add `eksctl install flux` command * Bump github/2opremio/flux * Fix typo * Refine missing pod error detection * Avoid commit error when manifests already exist * Fix missing parameter * Address code review: flux -> Flux in CLI args' help * Address code review: clearer call to action w.r.t. Flux SSH key * Use upstream Flux version Now that fluxcd/flux#2287 is merged we can use upstream Flux * gofmt -s -w pkg/ctl/install/install.go * Address code review: use CreateOrUpdate instead of kubectl * Address code review: improve use of RawExtensions and CreateOrUpdate * Address code review: improved output of eksctl help install flux * Address code review: rename import: k8serrors -> apierrors ... in order to follow the same conventions as elsewhere in the codebase. * Address code review: add more context to comments? * Address code review: clearer command description? * Address code review: explain why we return Flux's SSH key * Rename kubernetes.JoinManifest* to ConcatManifest* ... and also change ConcatManifests to become a variadic function, since more flexible to use. * Add utilities to generate Kubernetes Namespace objects (+tests) * Use kubernetes.Manifest{,YAML} utilities to install Flux * Address code review: extract check of existence of namespace + update comments * Address code review: re-read manifests once amended * Create the Flux namespace in the same way as all other resources * Fix rebase: GetCredentials -> RefreshClusterConfig * Add pkg/kubernetes/client.go#RawClient#ClientOrUpdate higher-level method This should hopefully make it easier to leverage RawClient for simpler cases.
Simlarly to
linkerd install
,fluxctl install
is meant to print out and tweak the Kubernetes manifests needed to install Flux in a cluster.Its output is intended for piping into other commands such as: