You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When installing stacks/demos, the operator charts are installed with default Helm values.
It would be good to be able to
override operator Helm values in stacks (eg: specify the ListenerClass presets for listener-operator)
install/upgrade operators/release with custom Helm values (but be careful since the values are not consistent across all operators).
Considerations:
How to make this look nice (because the command line could get rather long if having to specify each operator's overrides).
Should we make it look under overrides/ (or similar) for ${listener-name}.yaml?
Should there be a flag to opt-in/out so that if the overrides/ (or similar) exists, it can be igored?
Should we allow inlined values overrides in the stack definition, or just use the above?
Also, see issue about listener-operator (not only for stacks/demos): #356
Implementation
Add a new CLI argument --operator-values (which takes a file path).
Deserialise the values file BTreeMap<String, Value> (where String is the operator name).
For the operator being installed, extract the applicable values and blast them over to helm as a string.
listener class preset order of precedence: Auto Discovery < from --operator-values < from --listener-class-preset.
We might need to refactor the listener-class-preset (feat: Support configuring ListenerClass preset (with sensible defaults) #414) code so that we can determine whether --listener-class-preset was explicitly set (which should override whatever is in the operator-values.yaml), or if the preset came from autodetection (which should be overridden by the preset defined in the operator-values.yaml for listener-operator (if it is set)). Maybe need something like:
When installing stacks/demos, the operator charts are installed with default Helm values.
It would be good to be able to
Considerations:
overrides/(or similar) for${listener-name}.yaml?overrides/(or similar) exists, it can be igored?Also, see issue about listener-operator (not only for stacks/demos): #356
Implementation
--operator-values(which takes a file path).BTreeMap<String, Value>(where String is the operator name).--operator-values< from--listener-class-preset.--listener-class-presetwas explicitly set (which should override whatever is in the operator-values.yaml), or if the preset came from autodetection (which should be overridden by the preset defined in the operator-values.yaml for listener-operator (if it is set)). Maybe need something like: