I think that's worth getting done - it would be very handy! Maybe we can discuss it when implementing to figure out the way to do it?
On Mon, 21 Jul 2025 at 16:02, Josh McKenzie <jmcken...@apache.org> wrote: > I suppose the only concern would be maintaining this version in alignment > with what's going into the main cassandra.yaml as part of the regular > development. > > Seems like it'd be relatively easy to script something that'll generate > modularized config files based on the reference cassandra.yaml by > classifying different parameters based on file grouping. Not to scope creep > or add on to the CEP or anything, just thinking out loud; as follow up work > it could be useful. > > From a technical perspective having a bi-directional sync that'd just dump > things into a "overflow" file from monolithic -> modular, and tacking on at > the end of cassandra.yaml under an overflow section for things not > classified in the script from modular -> monolithic config shouldn't be too > complex. If that proved stable, integrating that into the build process and > even adding a checkstyle job target warning on non-classified configuration > parameters could tighten the whole thing up and give us a minimally > invasive way to support both through a transition. > > On Mon, Jul 21, 2025, at 9:41 AM, Johnny Miller wrote: > > I have added the section "Reference Example Configuration" - will see what > the feedback on this is. I suppose the only concern would be maintaining > this version in alignment with what's going into the main cassandra.yaml as > part of the regular development. > > On Mon, 21 Jul 2025 at 15:24, Josh McKenzie <jmcken...@apache.org> wrote: > > > That sounds useful to me. > > I'd like to see us move to "modularized by default"; our current config > being 2839 lines of .yaml > <https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml> is a > bad experience for both new and old users. Starting with examples of the > new paradigm and then refactoring config out over time for the default > config is a path forward I'd support. > > On Mon, Jul 21, 2025, at 9:18 AM, Johnny Miller wrote: > > One feature I was thinking of adding to the CEP was to have an example > yaml config setup using the includes with the config grouped logically so > people have a reference example in the conf? Would this be a good idea? > > On Fri, 18 Jul 2025 at 19:57, Johnny Miller <johnny.p.mil...@gmail.com> > wrote: > > Hello 👋 > > We would like to propose CEP-51: Support Include Semantics for > cassandra.yaml for adoption by the community: > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-51+Support+Include+Semantics+for+cassandra.yaml > > This CEP proposes adding completely optional include directives to > Cassandra's configuration system, allowing users who need it to split their > cassandra.yaml into multiple files for better security, organization, and > deployment flexibility. No changes are made to the default cassandra.yaml, > and this feature is entirely opt-in. > The proposed include directives (include, include_if_exists, and > include_dir) enable organizations to: > > - Apply the principle of least privilege by separating sensitive > security configurations into files with restricted permissions > - Better organize large configuration files by logical subsystems > - Simplify configuration management in environments where different > teams manage different aspects of the cluster > - Follow established patterns already present in PostgreSQL, MySQL, > Redis, NGINX, and other widely-used systems > > Key design principles: > > - Zero impact on users who don't use the feature > - No recursive includes (only the main cassandra.yaml can contain > include directives) > - No duplicate configuration keys allowed (each setting must appear in > exactly one file) > - Clear error messages for troubleshooting > > This enhancement addresses real operational challenges faced by > organisations with strict security requirements or complex deployment > needs, while maintaining complete backward compatibility and requiring no > changes to existing deployments. > > Thanks in advance for your time and feedback. Please keep the discussion > on this mailing list thread. > > Regards, > > Johnny > > > >
