+1 One small bit of feedback - in testing: > Unit Tests > > • Include file loading with all three directive types > • Rejection of include directives in included files > • Detection of duplicate configuration keys across files > • Error messages for duplicate keys include file and line numbers > • Error handling (missing files, parse errors) > • Path resolution (absolute/relative) We should ensure we test combinations of required, optional, and load directory with valid, invalid and overlapping data to ensure that the intersection of those various paradigms doesn't let invalid config slip through the cracks
On Fri, Jul 18, 2025, at 2:27 PM, Jeff Jirsa wrote: > In general I think this is reasonable, as long as we don't change the main > existing yaml, because doing so will probably mess up a lot of people's > packaging and tooling (I assume someone, somewhere, has a "copy the yaml into > the container" logic that doesnt know there may be multiple yamls). > > > > On 2025/07/18 17:57:03 Johnny Miller 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 > > >
