-
Notifications
You must be signed in to change notification settings - Fork 564
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question/Feature Request: Using Helmfile with Helm Plugins #214
Comments
@osterman Thanks for the great suggestion! I was also thinking to introduce a general plugin system to hook into helmfile, to unblock users from waiting until helmfile implements every feature that touches only part of helmfile. The part would be, in this case, the command used for installing or upgrading a single helm release. I try to outline it fitting to your example. Regarding your example, Calling each helm command - name: "portal"
namespace: "monitoring"
chart: "cloudposse-incubator/portal"
version: "0.1.0"
tasks:
installOrUpgradeRelease:
# call plugin "github" and use "upgrade" action
command: ["github", "upgrade"]
# In case you'd like to customize args...
# args: ["--additional-flag-1", "--additional-flag-2", {{ join .Tasks.UpgradeRelease.DefaultArgs ", " }}]
values:
... One of my dream feature on top of this is to add auto-selection of the plugin per release, according to its labels. Back to your example, I wonder if you end up using an external templating tool to avoid repeating the customization for every release in your helmfile.yaml. If we had a way to reuse the customization as a plugin, you just need label it to incorporate the customization: plugins:
- helm-github-support
releases:
- name: "portal"
namespace: "monitoring"
chart: "cloudposse-incubator/portal"
version: "0.1.0"
labels:
plugin.helmfile.github.io/helm-github-support/enabled: "true" WDYT on this plan? I'd appreciate any feedback! Also, thanks as always for your support.. |
Nice. Makes sense we should be able to install them some way like this. Probably needs to be a list of maps.
Good point; hadn't thought that far ahead. Would want to avoid relying on yet another layer, but if we must, using something like
Aha, makes sense. So the helm "primitives" used by
This feels like it would be a lot more complicated to implement and utilize in the helmfile. What about something like this:
|
Definitely, for finer-grained configuration!
Exactly 👍
One thing I'd like to clarify is that, I differentiate between helm plugins and helmfile plugins. In the above example,
Considering all the inputs given so far, I propose something like the below. 1. External helmfile pluginThis is for reusing helmfile plugins. plugins:
- name: helm-github-support
# source can be a path or an url to a helmfile plugin
source: https://github.com/cloudposse/helmfile-helm-github-support.git The imaginary helmfile plugin repository name: helm-github-support
taskOverrides:
installOrUpgradeRelease:
command: ["helm", "github", "upgrade"]
helmPlugins:
# helmfile will check if the helm plugin is already installed. If not, `helm plugin install --version master https://github.com/sagansystems/helm-github.git` will be run automatically by `helmfile`
- name: helm-github
source: https://github.com/sagansystems/helm-github.git
version: master 2. Inline helmfile pluginInline helmfile plugins are managed inside, and along with, plugins:
# Equivalent to the content of the plugin.yaml above
- name: helm-github-support
taskOverrides:
installOrUpgradeRelease:
command: ["helm", "github", "upgrade"]
# ... |
@osterman for the helm git plugin any reason it can't function similar to the |
A plugin systems is going to great increase the complexity of helmfile. I would be worry about trying to be the kitchen sink. |
@sstarcher Thanks for the comment! I'd like to hear your concerns on complexity more. My original purpose of the plugin system was preventing the helmfile core from growing limitlessly to support varying use-cases. But I do want to achieve that with minimum change(s) to helmfile. |
One more alternative to the above two, that seems minimal is to just introduce a feature to override specific command: releases:
- name: "portal"
namespace: "monitoring"
chart: "cloudposse-incubator/portal"
version: "0.1.0"
task:
overrides:
helmUpgrade:
command: ["helm", "github", "upgrade"] This allows us to defer introducing a complex plugin system, but still allow us to address this feature request, and gather more use-cases that can be supported by overriding or hooking into specific phase of helmfile. For example, it can be extended to: task:
overrides:
helmFetch:
# fetch the helm chart from your own store, without writing an helm plugin just for it
command: ["./yourownhelmfetch", "$CHART_NAME", "$CHART_VERSION"]
helmUpgrade:
command: ["helm", "github", "ugprade"]
hooks:
# Run chartify to generate a helm chart on demand
preUpgrade:
command: ["./chartify", "$RELEASE_NAME"]
# Notify successful deployment to Slack
postUpgrade:
command: ["./slacknotify.sh", "$RELEASE_NAME"] |
I agree with @sstarcher on the complexity issue. A plugin systems needs to be designed carefully and a lot of things are still changing inside of helmfile. I'd try to figure out the right set and semantics of the core commands first (for example apply was just added). As a comprise a limited pre- and post-hook system will probably be useful. It will probably solve the original use case (with some extra work) and I also have a similar use case where I'm currently using a Makefile to create and package up some charts from local git repositories and putting them into a repository to be consumed by helm via helmfile after that. |
Thanks for the feedback! Makes sense a lot. Let's keep discussing about the plugin system in another issues. In short term, solve the original issue plus your issue with something simpler! Do you think that the |
@sstarcher good point. It should work that way. |
Yes. I just looked at the helm-s3 plugin and helm-github should adapt its integration pattern as Erik and Shane have stated. But for all other cases of "I have my charts in hq, svn or my piggy bank" where no special plugin exists or other special actions are required to get or prepare the chart a @osterman Have you seen https://github.com/diwakar-s-maurya/helm-git? |
@elemental-lf was just looking at that last night as a result of this discussion. Looks interesting.
Only thing I didn't like is we have to remember to commit/update the index.yaml manifest. |
@osterman Your point about maintaining How about implementing a #295 will allow you run it automatically before helmfile run - name: external-dns
chart: ./charts/external-dns
hooks:
github:
phases: ["preChartLoad"]
command: ["helm", "github", "fetch", "--repo=git@github.com:kubernetes/charts.git", "--output-dir=charts/external-dns"] |
Right now, for our use-case my inclination is to just use a compatible plugin, rather than add this complexity to Helmfile per @sstarcher’s recommendation. TBH did not know plugins could work that way in helm. |
+1 for supporting helm-tiller (Tillerless Helm) |
It seems that the design og helm-tiller, actually makes this possible, by passing
to
|
Hi. Is this thread still alive? Helmfile format (almost same as above, but with versioning):
|
@johnlinvc From a user's perspective, I'd rather prefer Also, your suggested helmfile format looks good at glance! |
Were there any updates to this? |
what
helmfile
?use-case
helm-github
). It supports the identical interface tohelm upgrade
, but is invoked by callinghelm github upgrade ...
, wheregithub
refers to this plugin.suggested implementation
references
The text was updated successfully, but these errors were encountered: