Hi everyone,

I'd like to propose CEP-62: Cassandra Configuration Management via Sidecar
for discussion by the community.

CASSSIDECAR-266[1] introduced Cassandra process lifecycle management
capabilities to Sidecar, giving operators the ability to start and stop
Cassandra instances programmatically. However, Sidecar currently has no way
to manipulate the configuration files that those instances consume at
startup.

Many Cassandra settings (memtable configuration, SSTable settings,
storage_compatibility_mode) cannot be modified at runtime via JMX/CQL and
must be set in cassandra.yaml or JVM options files, requiring a restart to
take effect. Managing these files manually or through custom tooling is
cumbersome and lacks a stable API.

This CEP extends Sidecar's lifecycle management by adding configuration
management capabilities for persisted configuration artifacts. It
introduces a REST API for reading and updating cassandra.yaml and JVM
options, a pluggable ConfigurationProvider abstraction for integration with
centralized configuration systems (etcd, Consul, or custom backends), and
version-aware validation to prevent startup failures.

This CEP also serves as a prerequisite for future Cassandra upgrades via
Sidecar. For example, upgrading from Cassandra 4 to Cassandra 5 requires
updating storage_compatibility_mode in cassandra.yaml. The configuration
management capabilities introduced here will enable Sidecar to orchestrate
such upgrades by updating configuration artifacts alongside binary version
changes.

The CEP is linked here:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-62%3A+Cassandra+Configuration+Management+via+Sidecar

Looking forward to your feedback!

Thanks,

Paulo

[1] - https://issues.apache.org/jira/browse/CASSSIDECAR-266

Reply via email to