Remove helmfile --args
#1804
Comments
|
one thing which it might affect is an argoCD plugin https://github.com/travisghansen/argo-cd-helmfile/blob/master/src/argo-cd-helmfile.sh#L242 not sure though |
|
@vavdoshka Thanks for sharing! And... Whoa! I've never expected it to work like that. A So, the usage of @travisghansen What was your primary motivation to use I think the use of |
|
I think it's nice to have an ability to pass through generic args to the helm template command (there was an issue about this specifically...I'll see if I can find it). For example just today I had to use this to pass Likely unrelated, but I ran into issues using the |
Yes, it is very likely to break. We have no complete list mapping that knows "which helm command supports which args", neither in helmfile nor in chartify, which makes implementing your desired feature correctly very hard. |
Can we just add it to helmfile-template as a dedicated flag? |
|
Well, let me be more clear. I know it is a very "nice to have" feature. What I'm saying is implementing it correctly seems too hard from my perspective. If anyone can come up with a nice way to implement it in a way that works through the helmfile's code, including Otherwise, adding dedicated flags to |
|
Yeah, I want to say it blew up on the A dedicated flag to template seems ideal honestly to keep pollution down. I'm only using it with Appreciate the dialog and willingness to work jointly! |
|
BTW, I'm using that plugin fairly heavily with |
|
@travisghansen Thanks for the constructive feedbacks! I very much appreciate it. I've still some idea to try on Also, I've created #1812 to discuss about Helmfiel with ArgoCD. If you could come up with any topics around that, I'd appreciate your comments. Lastly... shouldn't |
|
Thank you for the great tool! I know it can get tiring maintaining such a project for various reasons.
Does that make sense why I keep it out of the I can provide some concrete examples from my own charts if that's helpful.. |
|
@travisghansen Thanks for confirming! It's now crystal clear that it shouldn't be in helmfile.yaml 👍 |
|
It’s not a bad feature to have by the way, there are use cases when the templating tool may not have access to live cluster info so having a failswitch for it is nice. |
|
Hello! I completely agree with the need to support the I was trying to use this possibility (via the integration script from @travisghansen ) to dynamically propagate the target cluster API capabilities, which are made available by ArgoCD as build environment - to the helm for correct render of templates. However, it seems like it is still not working. However, Here is example of this behaviour: #snippet from Helm chart using capabilities
....
{{- if .Capabilities.APIVersions.Has "cert-manager.io/v1alpha3" -}}
apiVersion: cert-manager.io/v1alpha3
{{- else -}}
apiVersion: certmanager.k8s.io/v1alpha1
{{- end }}
# invoke template with `args` passing a single api-versions flag
helmfile -l chart=cert-issuer template --args "--api-versions=cert-manager.io/v1alpha3"
---
# Source: cert-issuer/templates/self_signed_issuer.yaml
apiVersion: cert-manager.io/v1alpha3
kind: ClusterIssuer
metadata:
name: kfrfpr-issuer-ca
spec:
ca:
secretName: ca-secret
#invoke template with `args` passing several api-versions flags, where first is not the required one
helmfile -l chart=cert-issuer template --args "--api-versions=cert-manager.io/v1alpha2 --api-versions=cert-manager.io/v1alpha3"
---
# Source: cert-issuer/templates/self_signed_issuer.yaml
apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
name: kfrfpr-issuer-ca
spec:
ca:
secretName: ca-secret
# running the later command in debug mode, you can see that only the first flag was passed downward to the helm executable
helmfile --debug -l chart=cert-issuer template --args "--api-versions=cert-manager.io/v1alpha2 --api-versions=cert-manager.io/v1alpha3"
....
Templating release=cert-issuer, chart=../cert-issuer
exec: helm template cert-issuer ../cert-issuer --version 1.2.1 --namespace cert-manager --values /var/folders/j8/4x2hx6_13sq78dh_2cqkz99m0000gq/T/values595035734 --api-versions=cert-manager.io/v1alpha2 --debugBTW, possibility to pass the args for templating can also become pretty useful if the Helm tool community will finally agree to re-introduce the As helm Hopefully, the Helm3 will allow to explicitly specify target K8s version for template command and than we will need to somehow propagate it down from helmfile. The |
|
Interesting, are you saying that |
|
The problem is coming not from the script (i was author of that PR:) ) but from the helmfile internal implementation which seem to keep only one of multiple args while helm tool requires to pass multiple args in this way: As mentioned earlier and tested today, until this problem in helmfile is fixed (so that api-versions from command line are passed completely), the only workaround to dynamically pass the api-versions into helmfile logic is to use specially crafted snippet - in that case helmfile correctly propogates it down to helm: Currently, i have to add that snippet as common behaviour to all helmfiles even though using the metnioned script. Onec issue 457 is fixed and if |
|
Awesome thanks for the contribution and the snippet! I don’t think the intent is to remove the functionality of |
|
@travisghansen Thanks for the comment! Yeah, something like that. As long as @GolubevV Your usecase makes sense a lot. But shouldn't we just enhance Helmfile to support your use-cases natively? Do you need to set apiVersions via envvars dynamically on helmfile run, and is that all you need? What if helmfile.yaml's |
|
If I understand your suggestion about the env var that would actually work quite nicely yes. May want to make that an argument to the template sub command to allow folks to opt-in/out. EDIT: or do something like helm secrets does and automatically alter behavior based on detection of running in argocd - https://github.com/jkroepke/helm-secrets#argocd-support |
|
I agree that env var can help but question is - what should be the name of that var? In that regard, I like the idea of @travisghansen to implement runtime detection to be able to automatically propagate/map some ArgoCD build variables down to helmfile internal variables, like:
It can be one of those improvements for better integration that we want to track in #1812 BTW, In defence of the |
|
@GolubevV Hey!
Probably.
All these seem to make sense to me. Also, would you mind writing a more detailed feature request with how you'd exactly like those envvars to be mapped to helmfile settings, and link it from #1812 for reference? That way, designing/implementing the feature would be more approachable and feasible. Currently, everyone writes many ideas about ArgoCD integration in various places, which is starting to kill me
As I've been repeatedly saying to everyone, I'd like everyone to submit feature requests to add necessary and concrete flags to helmfile-template. That said, writing a feature request to add I'd remove I consider the use of |
|
Another voice on args #1853 (comment) |
It won't be easy to have an exhaustive list of necessary and concrete flags since the upstream helm will evolve. Currently I rely on There is bug in state file directive though. will produce It seems stripping My 2 cents:
|
|
@yujunz Hey! Thanks for the feedback. But I'm feeling like I'm repeating the same call again and again.
This turns out to be impossible to me. If anyone has some time to speculate it and able to come up with a concrete idea on how it should look like, please help me. The hardest part if that we really don't have a concrete spec around how current Someone uses it in a way, another uses it in another way. Everyone brings in various ideas. I try to summarize, balance all and try to come up with the best idea to move forward. And that turned out to be just removing |
|
It is pretty common to pass args as is in tool chains. For example It doesn't have to be called After all, this will not conflict with concrete flags/config which can be parsed by helmfile but complement them for flexibility and extensibility. Does it make sense? |
|
@yujunz Sorry but no. I raed For example |
TIL. I was expecting For arguments specific to each steps, either implement it as what you have suggested
Or with specific flags ,e.g. What do you think? @mumoshu |
@yujunz Thanks. Yeah, maybe. I understand that it might cover most cases.
Yeah, this might work too. The only concern for me is the possibility that people start asking various questions for various combinations of yaml settings and Maybe |
|
@mumoshu if I agree that We for example are using the |
|
Thanks, everyone! |
|
@mumoshu I think it might still be good to address array style parameters and what should be done if anything about that. |
|
@travisghansen Hey! Sry but what was "array style parameters` thing? Where did we discuss about that before |
|
I don’t recall which issue it landed on but its the problem where specifying the same arg name multiple times results in only the last variant of it being passed down to helm (ie: |
|
@travisghansen Thanks! Sry but I can't recall either. Would you mind creating a dedicated issue for it, with a short concrete example of how you would use it, so that I can try to implement and test it. It's currently too vague for me to work on. |
|
@mumoshu start here I guess: #1060 (comment) |
|
First off, thank you for the awesome tool! Sorry to comment on an old issue, but what is the current expected behavior of helmfile template --args="--skip-tests"It passes the But if I pass in the I haven't tested this on 0.140.0 yet, but has anyone else seen similar behavior? Is this expected? |
|
We have no well-designed way to specify which helm commands receive which args from helmfile's |
|
@mumoshu I think that a better option is to transform args to go-template, similar to hooks, with two parameters:
It will allow any arguments while keeping backward compalibity. |
|
@AssafKatz3 Thanks. How would it look like in helmfile.yaml? Perhaps something like the below? Assuming the above isn't too far away from what you imagine, I'm wondering if how would declare customization on commands unrelated to releases, like |
That wouldn't work for our use case, we are passing |
|
Hi @mumoshu , |
|
Hi @dudicoco, |
Thanks @AssafKatz3. Personally I don't see a problem with just keeping
|
|
Hi @dudicoco, |
|
I was looking for a way to run a custom post-renderer script in my helmfiles and came across #1530 and then this issue. |
helmfile --argsis a historical artifact that only worked in the very beginning of the helmfile project. At that time helmfile sync only ran a single helm command.Nowadays a helmfile run involves many helm commands so --args doesn't make sense. Which custom args should be passed to helm template, helm template, helm diff, helm repo up, helm dep build, etc? Impossible to deduce.
Just drop it from helmfile, and alternatively provide more specific flags if necessary.
The text was updated successfully, but these errors were encountered: