Closed aaron-trout closed 1 month ago
This sounds to me like a fairly niche use case. Also, adding watches across namespaces like you suggest would complicate things a lot.
If there is more interest in this functionality, we might revisit this, but for now the approach you have taken, defining a volume without mounting it is a reasonable workaround.
I might add that to the documentation as a supported way of capturing such "rogue" ConfigMaps
or Secrets
.
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
If anybody want to implement it this should be quite straightforward to do. Just add the query here: https://github.com/wave-k8s/wave/blob/master/pkg/core/children.go#L53 in getCurrentChildren
. That should add owner references etc and trigger all the magic. Not sure if cross namespace watches would actually be an issue with owner refs.
Workaround for now would be to add those secrets/configmaps as (unused) environment variables.
In #155 I refactored the children code to support secrets/configmaps in other namespaces. This should be quite straightforward to implement now. Let me know if you still need it and I will add it.
I have an initContainer on one of my deployments which reads stuff directly from a Kubernetes Secret. This doesn't currently get picked up by Wave because that Secret is not in any volumes or env/envFrom.
It would be handy if there was an optional annotation to specify extra configmaps / secrets to watch. Something like:
For now, I have worked around this by defining a Volume but not actually mounting it into any containers in the pod.