> give us a minimally invasive way to support both through a transition. I'm caught up on the slack thread now; let's not even allude to nor discuss transitioning a default and just keep things constrained to adding new functionality and keeping it in sync. Don't want to derail things.
On Mon, Jul 21, 2025, at 11:37 AM, Johnny Miller wrote: > 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 >>>> >>
