A deployment may depend on a ConfigMap or Secret, it would be great if Flux could handle that in a reasonable fashion. Right now, if Flux tries to create or update a Deployment that references a configuration resource, it will result in a failing deployment.
As a starting point, we could do something simple where we lookup whether such resource exists in the cluster or the repository and refuse an update if it doesn't, if it exists only in the repository we can simply create it.
Being able to version configuration resource is something we could consider implementing (as it's something Kubernetes doesn't do), and it would be a great feature for the users, but it may be a little complex at first.
errordeveloper
All 8 comments
Being able to version configuration resource is something we could consider implementing (as it's something Kubernetes doesn't do), and it would be a great feature for the users, but it may be a little complex at first.
Ilya, interesting idea -- could you jot down here how you think this could work?
squaremo
on 2 Mar 2017
This should be fixed with the git-sync project? I.e. kubectl apply should apply all secrets/configmaps, etc.
philwinder
on 18 Apr 2017
This should be fixed with the git-sync project?
Yes exactly, once we expand it to all resources. Leaving open for now.
squaremo
on 20 Apr 2017
... could you jot down here how you think this could work?
Let me try to expand on this, with a few thoughts I've had recently... (This may be still now exactly what you were looking for, but I'm happy to elaborate as I get to understand how it would fit into the new git-sync architecture).
What I've been thinking lately is that it'd be really nice to have support for pod restarts on config updates, and provide some way for controlling such behaviour.
For example, if you have a pod that refers to a config map foo it won't restart if foo changes (IIRC if it is mounted as a volume, the content of files inside the volume would get updated, however the app would have to watch the files in that volume).
I'd suggest that we could automatically append hash of the config map or secret content to its name, but as an experimental/opt-in feature.
I think it should be fairly simple to add this if we ship it as an experimental feature that users can opt into (e.g. via an annotation on config maps and secrets), and then see how well it works for people.
There is more we might want to do when we get to implement some kind of blue/green feature, e.g. users will probably want to have one version of config map in blue pods and another in green pods. We should explore how the revisions of config objects and workload objects relate to the content.
A somewhat alternative approach would be to treat config object a way similar to how we treat workload images. Namely, each time new version of a config object appears in git repo, we create one in the cluster with a hash of its content appended to its name; then the user has some way of selecting which particular version of config object they want to use in each particular workload item and they can just opt-in for latest.
Also, a use-case we have heard from a user is that there exists a certain type of config objects that have to be synced between all namespaces (e.g. image pull secret), perhaps another story to keep in mind.
As I said, just a few thoughts for now, let's collaborate on more concrete use stories.
errordeveloper
on 24 Jul 2017
Flux now supports syncing ConfigMaps and Secrets.
samb1729
on 23 Mar 2018
Just to be sure:
What I've been thinking lately is that it'd be really nice to have support for pod restarts on config updates, and provide some way for controlling such behaviour.
This is not currently possible, right? Looks like Skaffold is in the same spot: https://github.com/GoogleContainerTools/skaffold/issues/97. And it may eventually be a feature of K8s itself: https://github.com/kubernetes/kubernetes/issues/22368.
I agree that it would be really cool (I certainly have deployments that I effectively want to update via ConfigMaps), but I can understand the call not implement that as part of flux.
tjanson
on 9 Aug 2019
Hi guys. Any idea why flux won't update a config map? I've updated it on the git branch, but Flux didn't apply the changes next time it ran (the log is clean, no exceptions). I've waited and then deleted the ConfigMap from K8S cluster, then waited for the Flux operator to recreate it and I still see the original contents of the map via kubectl describe cm/email-config and not what's in the repo itself. Am I missing something? Thank you.
demisx
on 17 Aug 2019
My apologies. The ConfigMap is actually updated by Flux. I missed it because the data keys output from kubectl describe cm is formatted in a different order, then the source. But all new keys and values are there!
demisx
on 17 Aug 2019
Related issues
eimarfandino
路
3Comments
cloudpea
路
3Comments
mar1n3r0
路
4Comments
astraldragon
路
3Comments
anwarchk
路
4Comments
Most helpful comment
Let me try to expand on this, with a few thoughts I've had recently... (This may be still now exactly what you were looking for, but I'm happy to elaborate as I get to understand how it would fit into the new git-sync architecture).
What I've been thinking lately is that it'd be really nice to have support for pod restarts on config updates, and provide some way for controlling such behaviour.
For example, if you have a pod that refers to a config map
fooit won't restart iffoochanges (IIRC if it is mounted as a volume, the content of files inside the volume would get updated, however the app would have to watch the files in that volume).I'd suggest that we could automatically append hash of the config map or secret content to its name, but as an experimental/opt-in feature.
I think it should be fairly simple to add this if we ship it as an experimental feature that users can opt into (e.g. via an annotation on config maps and secrets), and then see how well it works for people.
There is more we might want to do when we get to implement some kind of blue/green feature, e.g. users will probably want to have one version of config map in blue pods and another in green pods. We should explore how the revisions of config objects and workload objects relate to the content.
A somewhat alternative approach would be to treat config object a way similar to how we treat workload images. Namely, each time new version of a config object appears in git repo, we create one in the cluster with a hash of its content appended to its name; then the user has some way of selecting which particular version of config object they want to use in each particular workload item and they can just opt-in for latest.
Also, a use-case we have heard from a user is that there exists a certain type of config objects that have to be synced between all namespaces (e.g. image pull secret), perhaps another story to keep in mind.
As I said, just a few thoughts for now, let's collaborate on more concrete use stories.