search

k8ssandra / k8ssandra-operator

The Kubernetes operator for K8ssandra
https://k8ssandra.io/
Apache License 2.0
173 stars 78 forks source link

Add ability to set environment variables in containers deployed by k8ssandra-operator #649

Open Miles-Garnsey opened 2 years ago

Miles-Garnsey commented 2 years ago

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 ┆Issue Number: K8OP-200

adutra commented 2 years ago

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.

Miles-Garnsey commented 2 years ago

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.

jsanda commented 2 years ago

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.