Helm chart upgrades about keel

[sstarcher]

You would have a few options. One option would be to poll the chart repository for updates. Tiller also contains information for the release and what chart+version that release is part of, so it would be possible.

If interested I may have some time to help out. I currently have something that does the above functionality using the helm binary, but the the tiller grpc code.

My current process is simplistic.

• Query helm for a list of installed charts
• Given a list of helm repos query for updates to the installed charts

stable   	https://kubernetes-charts.storage.googleapis.com
local    	http://127.0.0.1:8879/charts
platform 	https://helm-readonly:[email protected]/repository/charts

• When an update is found run helm upgrade --version VER --recreate-pods --wait

In the keel world I imagine a new notification type that polls helm repositories or a webhook.
And an enhancement to the helm provider or a new provider for the chart updates.

I'm new to keel so feel free to let me know if my assumptions are off base.

[rusenask]

Hey, do you have in mind recreating chart with updated values.yaml?

[sstarcher]

I have in mind not changing the values.yaml and only modifying the chart version installed.

An example
Currently the chart stable/nginx-ingress is installed at version 0.7.1
A new chart is published of version 0.7.2 and an upgrade is issued to tiller to upgrade the chart. No values changes.

[rusenask]

Yes, makes sense.

1. How could keel know where the chart is located?

2. How on chart update event (I guess webhook is reasonable trigger) should it identify that particular release was created by this chart? Release name is not in the chart.

I guess both questions could be addressed with additional line in Keel config that lies in values.yaml with something like selfLink: stable/nginx-ingress

And event type should be slightly refactored to be more dynamic so we could have both registry and chart update events.

Does this sound reasonable?

[theogq]

I am looking for solution as @sstarcher describes. Does anybody know if there is something like that?

[posix4e]

This is still a blocker for us

[gaieges]

This is something that we would really need as well in order to get into production with keel.

One thought is that there can be a separate watcher on the helm repo, such that if a chart gets updated, the chart is what gets the helm upgrade or install command, and it contains a annotation such as subscribeToUpdatesForRepo: myrepo/mychart.

Authentication would be key for us as well here (the helm repos are private)

This could be separate to the subscription to the image updates and fit into your existing model and architecture (I think).

[rbq]

Handling this via Keel would mean that, instead of one single source of truth for a deployment, one revision would be annotated with configuration for the following ones. This seems less than ideal to me. (What happens if I annotate revision x to pin the deployment to a specific version range of the chart, but then roll back to x-1?)

I believe the right way to do this is by running some kind of Operator that watches (a) CRs representing application deployments with values and (b) their repos, performing all lifecycle operations (installation/removal/upgrade) as needed.

Maybe it would then make sense to have a Keel version that watches Helm repos and updates CRs representing deployments, but leaves the actual upgrade to the controller that handles those CRs—e.g. fluxcd/helm-operator, giantswarm/chart-operator, or even Chart-specific Operators that don't support watching a repo on their own.

But I really don't think Keel should become an incomplete Operator that only supports the upgrade step of a Helm deployment's lifecycle.