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 > > >
