Hi there,
How does the operator deal with configuration changes in different elastic versions (ie. added/renamed env vars, etc)
Hey @Kyle_White,
ECK is aware of the stack version based on the version field you provide in the spec.
Any setting entirely managed by ECK (ie. the ones you don't see that ECK applies behind the scenes) is handled correctly.
Any setting you apply yourself (ie. through config: in the spec or podTemplate:) isn't checked by ECK and is "your responsibility".
If some of those settings are incompatible with a newer version of Elasticsearch, it is likely that Elasticsearch will fail to start. Since configuration changes are applied through a rolling upgrade, you would notice that the upgrade is stuck since the first upgraded node cannot start properly. ECK will not move on with upgrading the other nodes with the wrong configuration. At this point you can edit the spec again to apply the correct configuration settings, so ECK can restart the invalid Pod again.
Let me know if that makes sense to you!
Thanks for the quick reply! (and apologies for my very slow one!)
I'm curious how ECK is managing this behind the scenes. Ie. Does the operator hard code each the elastic config at each version and use that to determine what to use? Or is there something more abstract.
It looks like the hard coded route, but I was wondering if you had or were planning abstractions for this
Yeah we basically need to keep track of per-version settings. Eg. don't apply v6.x setting on v7.x, etc. So far those differences can easily be handled with a switch/condition on the version where we build the config pieces: https://github.com/elastic/cloud-on-k8s/blob/25bcb4a0d131debbbff003e6c83e7c5eccd9e269/pkg/controller/elasticsearch/settings/merged_config.go#L102-L112
So we did not feel the need for a smarter abstraction here (keep things simple if possible!).