Closed andyedwardsibm closed 5 years ago
You're right, Wave should definitely include support for these! I completely missed this when doing the original implementation
At present, when parsing we just hash the whole configmap/secret for simplicity's sake, so I'd be tempted to start with a PR to add the parsing of the envVar
section and just adding the whole secret/configmap (as we do with other sources) and then follow up with a second PR which makes the changes to only hash the individual keys within the secrets and configmaps.
WDYT?
That's a possibility, yes, and I might be able to whip up a quick PR, but for our use case we'd want the final behaviour of spotting individual key changes.
I'm really close to finishing the code that handles specific keyed items: I've just got to handle the optional field and those fields being potentially missing (and extend the unit tests for that situation).
PR submitted (https://github.com/pusher/wave/pull/34) that includes the env
section, only using the specified keys in the hash, and handling the optional
flag as best I can.
@andyedwardsdfdl Can this issue be closed now #34 is merged?
Yep, I believe this is now resolved, and ready to go into the next release.
This operator is exactly what we're looking for, but our use of secrets involves explicitly pulling in individual secrets to the deployment as separate envs. Wave only considers whole ConfigMap/Secret entries in the
containers.envFrom
andvolumes.volumeSource
sections though.For example, for the deployment snippet below, changes to
EXPLICIT_A
in ConfigMapconfig-explicit
, andSECRET_A
in Secretsecrets
are not noticed.I've been prototyping some changes in a fork that includes discovery of env entries, and only includes the data from the specified
*KeyRef
in the hash calculation. This has basically involved adding a newConfigObject
type and putting theObject
inside (so Wave can still pass it to k8s), along with metadata on whether an individual field is specified, and what that field is (that can be used by the hashing code). I have something that seems to work in a minikube test environment. Would you be open to me submitting a PR?