Closed vdice closed 4 years ago
@vdice, Can you assign this to me
I have started working on helm3 mixin support: https://github.com/MChorfa/porter-helm3 and I want to propose to adapt the helm2 mixin regarding the version that was requested at Buildtime, thus the behavior of the mixin will run accordingly. So, we don't have to maintain 2 projects that are very similar and prepare for the fade-out of helm2. WDYT?
Diff | Helm2 | Helm3 |
---|---|---|
Schema | none | --purge is removed for uninstall step and --namespace is required for uninstall step |
Init | initTiller is required | initTiller Logic is removed |
Build | kubectl is not required | kubectl is not required |
Install | require --name flag |
removed --name flag |
Uninstall | require --purge flag |
removed --purge flag |
Upgrade | require --name flag |
removed --name flag |
Invoke | no-change | no-change |
@MChorfa Seems like there would be differences in the allowed yaml based on which version of the mixin that you are using then, correct?
If so, then the new combined helm mixin should definitely implement the lint
command that was just put in place in the v0.25.0-beta.1 release so that it can validate that the porter.yaml is correct based on the version selected.
Another question to consider is what should the default version of helm be when the user doesn't select one? Or should version be required? You don't need answers now, just putting it out there for people to think about.
Hello @carolynvs, Actually, for install/upgrade the yaml's don't change. except for uninstall where purge is not allowed in helm3. Definitely the linter will be a very nice way to ensure the correct structure of the targeted Helm instance.
I guess the default version would be Helm3, because of easiness of installing and doesn't require Tiller and help people to move from 2 to 3.
Thank you,
Thank you @vdice , retrofitting back the same behavior to Helm3 mixin
@MChorfa when convenient, can you create a new issue with the notes/discussion around https://github.com/deislabs/porter-helm/issues/50#issuecomment-606344338 ? I think this can/should live on.
Closing this as it has been implemented in #64
Support a Helm version declaration and use this value, when provided, to download the corresponding
helm
cli binary at build-time. For example, thehelm
mixin declaration in a Porter manifest could look like:We'd then update the installation steps/lines added to the generated invocation image Dockerfile to download the
v1.15.1
helm binary.