k8ssandra
K8SSAND-1727 ⁃ Add ability to set environment variables in containers deployed by k8ssandra-operator
What is missing?
It doesn't currently appear to be possible to set environment variables in the containers which k8ssandra-operator deploys.
Why do we need it?
There are various aspects of Cassandra (e.g. LOCAL_JMX) which can only be controlled via environment variables. It would be useful to offer this functionality for debugging (e.g. here).
Advanced use cases (e.g. where additional agents are added to Cassandra, or custom scripts are run at startup) would also benefit from this feature.
Another option would be to merge this PR, which would offer another way of instantiating environment variables at Cassandra startup.
┆Issue is synchronized with this Jira Story by Unito
I am not convinced we should let users tweak environment variables directly.
LOCAL_JMX is imho the perfect example of an env variable that users should definitely not be able to define themselves as it mixes two orthogonal concepts: authentication, and remote access.
Regarding agents, I think it's the same: if an agent gets added to the classpath, that's in response to so more high-level feature enabled by the user (e.g. enabling metrics, or cdc); then the operator would include the required agents in the classpath, and also set the appropriate env variables – no need for the user to set those themselves.
as it mixes two orthogonal concepts: authentication, and remote access.
Which is definitely bad, but that is an issue in Cassandra upstream and we aren't in a position to do much to make it work in a more rational way.
We need to support Cassandra as it is, rather than trying to overlay our own logic which diverges from the community IMO. Unfortunately, LOCAL_JMX is the way that they do it.
RE agents, we should not assume that we know about every agent, plugin, etc. that users will want to utilise. Some of these can be in-house and proprietary to an organisation.
I agree with @adutra about users configuring env vars and agents in that it should be done as a result of some higher level action.
I also agree that we shouldn't make assumption about other agents that folks might want to use. Let's consider how to handle that if/when it becomes a concern, i.e., a user asks for related feature.
