> Once done, we might have a custom ConfigurationLoader on Cassandra's > classpath which will fetch the configuration remotely - from the very store > we would have remotely too. That way, nothing would ever be on disk. Remote only introduces a single point of failure and reliance on an external system w/out some kind of local caching. Makes sense to me to go local first then augment w/support for remote w/fallback to local on failure as a follow-on effort.
Also: I think the remote support is a great idea and would be a solid future default. Just something it seems like we'd need to build up to to have robust fallback and availability mechanisms. On Tue, Mar 17, 2026, at 5:04 PM, Joel Shepherd wrote: > Hi Paulo - Interesting CEP, and potentially very useful: thanks! > > I was wondering about several things as I was reading through it: > > * Authorization - Particularly for operations that mutate configuration > (either in the store or at run-time for the node). What are the authorization > controls. > > * Integrity - I see you're using hashes for conflict detection. Have you > considered using them as integrity checks as well: e.g., to guarantee the > configuration deployed for the node/instance to load at runtime is the same > configuration computed by the configuration manager (I think that's the right > component)? This would be a guard against bugs, network gremlins, file system > gremlins, etc., quietly corrupting the configuration that the node will > eventually read. > > * Visibility - As an 'administrator' how do I determine how much of my > cluster is running on the latest configuration, and which nodes specifically > aren't? Is it up to me to implement that monitoring? > > * Rollback/forward - If I push a bad configuration change, how do I as the > the administrator respond to that? For example, is there an assumption that > I'll be managing my configuration in a RCS somewhere and will be expected to > quickly retrieve a known-good older revision from it and push it through > sidecar? It might be helpful to have a "user experience" section in the CEP > to describe how you envision users managing their cluster's configuration > through this tool: what they're responsible for, what the tool is responsible > for. > > Thanks -- Joel. > > On 3/17/2026 9:32 AM, Paulo Motta wrote: >> >> 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
