Comments (8)
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.
from keel.
Hey, do you have in mind recreating chart with updated values.yaml?
from keel.
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.
from keel.
Yes, makes sense.
-
How could keel know where the chart is located?
-
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?
from keel.
I am looking for solution as @sstarcher describes. Does anybody know if there is something like that?
from keel.
This is still a blocker for us
from keel.
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).
from keel.
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.
from keel.
Related Issues (20)
- *v1beta1.CronJob: the server could not find the requested resource HOT 2
- Notifications feature proposal
- Website search bar not working
- Initial tag required? HOT 1
- High CPU usage HOT 5
- Fix documentation to add "Registry" webhook
- Bump helm chart release HOT 4
- Helm chart: Ingress not working with release name
- Add support for ntfy HOT 1
- Can keel handle multiple containers in a pod deployment? HOT 3
- Cannot use registry mirror
- keel is using deprecated api /apis/batch/v1beta1/cronjobs
- Helm chart still uses app version 0.19.1
- Timeout errors trying to use polling HOT 1
- Slack integration is broken
- Allow ignoring/skipping version
- GCP registry returns 404 on digest check
- Feature request: Helm repositories
- Keel updates regexp deployment after restarting
- Keel SMTP notification error
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from keel.