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
