keel-hq / keel

Kubernetes Operator to automate Helm, DaemonSet, StatefulSet & Deployment updates
https://keel.sh
Mozilla Public License 2.0
2.42k stars 280 forks source link

Grouped approvals #369

Open plumdog opened 5 years ago

plumdog commented 5 years ago

In many situations, I have multiple deployments/cronjobs that use the same image. For eg, where I have deployment running website, and several cronjobs using that same image to run commands to do things.

I would like to be able to use approvals to update all of these at the same time from slack. They each already have labels to signify that they are part of the same environment (eg, all belong to the same helm release), but with approvals as they are I'd need to make sure I approved each usage of the updated image within an environment:

I'm not sure what might be a sensible way of handling this. Maybe have some notional parent deployment that says "keel, when you update me with an image, also update other things that match my labels this and that" or have a configmap with some annotations that keel inspects to make these decisions.

Extra thought: it would be great if this could handle updating different images all-at-once too, eg if I have a web image and an app image that I want to update in tandem.

Thoughts?

rusenask commented 5 years ago

maybe we could have

keel image approve quay.io/foo/bar:1.2.3

and then whatever uses that image gets a green light for auto updates?

plumdog commented 5 years ago

In my case, that wouldn't solve the problem. I have situations where there's 3 environments of the same thing, eg, stage, uat and prod. I'd then want to have full auto deployment on stage, but then separate approvals for uat and prod. So to handle this I'd need some way of saying "keel approve env=uat foo:1.2.3" or something, and it update all things that match that label, maybe.

rusenask commented 5 years ago

Maybe approvals could also work via selectors?

plumdog commented 5 years ago

Broadly yes, but I think there should be strong defences against accidentally updating something you didn't mean to. Eg keel approve k8s-app=kube-dns my/evil/image should definitely not work (unless I'd added annotations to allow it, for some reason).

I wonder if something like being able to link a deployment/cronjob/daemonset to a configmap would make sense. Eg, I add an annotation to my deployments and cronjobs like keel.sh/config: myconfigmap.myconfigkey instead of the usual keel labels/annotations. Then myconfigmap.myconfigkey has some yaml or something to configure keel's behaviour, basically the same as the existing labels and annotations. Then, because all the deployments/cronjobs/daemonsets in my release share the same config, keel knows that they all get updated and approved together. And you'd say keel approve config/myconfigmap.myconfigkey myimage:1.2.3 or something tidier, maybe. In the simplest case, I guess it should only handle cases where they all use the same image, but in theory could handle more complicated configuration where I can approve several image changes for my release at once.