Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Jordan West]

Following up on this. Sounds like we can take this to a vote? I’m happy to
sheperd if another committee or PMC member is not available

On Fri, Aug 1, 2025 at 01:46 Jeff Jirsa  wrote:

> Hey folks
>
> Helping nudge this along - any dissent? Anyone with concerns they’d like
> addressed before we move towards a vote?
>
> - Jeff
>
> On Jul 26, 2025, at 12:35 PM, Ekaterina Dimitrova 
> wrote:
>
> 
>
> Hi,
>
> Just wanted to mention that we already have some config related to
> duplicate keys in cassandra.yaml. (That doesn’t mean we cannot
> extend/improve things further, of course)
> From our docs:
>
> CASSANDRA-17379  was
> opened to improve the user experience and deprecate the overloading. By
> default, we refuse starting Cassandra with a config containing both old and
> new config keys for the same parameter. Start Cassandra with
> -Dcassandra.allow_new_old_config_keys=true to override. For historical
> reasons duplicate config keys in cassandra.yaml are allowed by default,
> start Cassandra with -Dcassandra.allow_duplicate_config_keys=false to
> disallow this. Please note that key_cache_save_period,
> row_cache_save_period, counter_cache_save_period will be affected only by
> -Dcassandra.allow_duplicate_config_keys.
>
> There are people who actively use the overloading in their environments so
> backward compatibility is important.
>
> Best regards,
> Ekaterina
>
> On Wed, 23 Jul 2025 at 4:05, Johnny Miller 
> wrote:
>
>> That's a really good idea! I have updated the CEP to include this
>> duplicate_key_policy functionality and corresponding test scenarios.
>>
>> On Tue, 22 Jul 2025 at 16:35, Patrick McFadin  wrote:
>>
>>> Another hit from the DevOps request backlog. I'm glad this has
>>> finally turned into something formal. This will make CI/CD much easier. One
>>> thing I hope this fosters more of is the sharing of configs. For example,
>>> "here are my recommended storage settings for EBS."
>>>
>>> The CEP aborts on any duplicate key. For the people doing GitOps, there
>>> will be a need for layering a read-only baseline `cassandra.yaml` with
>>> environment-specific or secret files. This is exactly the way Argo CD/Helm
>>> handles value precedence. This is typical in cloud native environments. I
>>> propose a modification that allows an *opt-in* policy switch:
>>>
>>> duplicate_key_policy: { ABORT (default) | LAST_WINS | WARN }
>>>
>>> * ABORT  – current behaviour, startup fails on duplicates.
>>> * WARN   – duplicates allowed, last key wins, but every override is
>>> logged.
>>> * LAST_WINS – same as WARN, but without log
>>>
>>> On Mon, Jul 21, 2025 at 7:01 AM Josh McKenzie 
>>> 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 
 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
 
 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 2

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Jeff Jirsa]

Hey folksHelping nudge this along - any dissent? Anyone with concerns they’d like addressed before we move towards a vote? - Jeff On Jul 26, 2025, at 12:35 PM, Ekaterina Dimitrova  wrote:Hi,Just wanted to mention that we already have some config related to duplicate keys in cassandra.yaml. (That doesn’t mean we cannot extend/improve things further, of course)From our docs:CASSANDRA-17379 was opened to improve the user experience and deprecate the overloading. By default, we refuse starting Cassandra with a config containing both old and new config keys for the same parameter. Start Cassandra with -Dcassandra.allow_new_old_config_keys=true to override. For historical reasons duplicate config keys in cassandra.yaml are allowed by default, start Cassandra with -Dcassandra.allow_duplicate_config_keys=false to disallow this. Please note that key_cache_save_period, row_cache_save_period, counter_cache_save_period will be affected only by -Dcassandra.allow_duplicate_config_keys.There are people who actively use the overloading in their environments so backward compatibility is important.Best regards,EkaterinaOn Wed, 23 Jul 2025 at 4:05, Johnny Miller  wrote:That's a really good idea! I have updated the CEP to include this duplicate_key_policy functionality and corresponding test scenarios.On Tue, 22 Jul 2025 at 16:35, Patrick McFadin  wrote:Another hit from the DevOps request backlog. I'm glad this has finally turned into something formal. This will make CI/CD much easier. One thing I hope this fosters more of is the sharing of configs. For example, "here are my recommended storage settings for EBS." The CEP aborts on any duplicate key. For the people doing GitOps, there will be a need for layering a read-only baseline `cassandra.yaml` with environment-specific or secret files. This is exactly the way Argo CD/Helm handles value precedence. This is typical in cloud native environments. I propose a modification that allows an *opt-in* policy switch:    duplicate_key_policy: { ABORT (default) | LAST_WINS | WARN }* ABORT  – current behaviour, startup fails on duplicates.* WARN   – duplicates allowed, last key wins, but every override is logged.* LAST_WINS – same as WARN, but without logOn Mon, Jul 21, 2025 at 7:01 AM Josh McKenzie  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  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 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  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.yamlThis 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, i

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Ekaterina Dimitrova]

Hi,

Just wanted to mention that we already have some config related to
duplicate keys in cassandra.yaml. (That doesn’t mean we cannot
extend/improve things further, of course)
>From our docs:

CASSANDRA-17379  was
opened to improve the user experience and deprecate the overloading. By
default, we refuse starting Cassandra with a config containing both old and
new config keys for the same parameter. Start Cassandra with
-Dcassandra.allow_new_old_config_keys=true to override. For historical
reasons duplicate config keys in cassandra.yaml are allowed by default,
start Cassandra with -Dcassandra.allow_duplicate_config_keys=false to
disallow this. Please note that key_cache_save_period, row_cache_save_period
, counter_cache_save_period will be affected only by
-Dcassandra.allow_duplicate_config_keys.

There are people who actively use the overloading in their environments so
backward compatibility is important.

Best regards,
Ekaterina

On Wed, 23 Jul 2025 at 4:05, Johnny Miller 
wrote:

> That's a really good idea! I have updated the CEP to include this
> duplicate_key_policy functionality and corresponding test scenarios.
>
> On Tue, 22 Jul 2025 at 16:35, Patrick McFadin  wrote:
>
>> Another hit from the DevOps request backlog. I'm glad this has
>> finally turned into something formal. This will make CI/CD much easier. One
>> thing I hope this fosters more of is the sharing of configs. For example,
>> "here are my recommended storage settings for EBS."
>>
>> The CEP aborts on any duplicate key. For the people doing GitOps, there
>> will be a need for layering a read-only baseline `cassandra.yaml` with
>> environment-specific or secret files. This is exactly the way Argo CD/Helm
>> handles value precedence. This is typical in cloud native environments. I
>> propose a modification that allows an *opt-in* policy switch:
>>
>> duplicate_key_policy: { ABORT (default) | LAST_WINS | WARN }
>>
>> * ABORT  – current behaviour, startup fails on duplicates.
>> * WARN   – duplicates allowed, last key wins, but every override is
>> logged.
>> * LAST_WINS – same as WARN, but without log
>>
>> On Mon, Jul 21, 2025 at 7:01 AM Josh McKenzie 
>> 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 
>>> 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
>>>  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 
>>> 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

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Johnny Miller]

That's a really good idea! I have updated the CEP to include this
duplicate_key_policy functionality and corresponding test scenarios.

On Tue, 22 Jul 2025 at 16:35, Patrick McFadin  wrote:

> Another hit from the DevOps request backlog. I'm glad this has
> finally turned into something formal. This will make CI/CD much easier. One
> thing I hope this fosters more of is the sharing of configs. For example,
> "here are my recommended storage settings for EBS."
>
> The CEP aborts on any duplicate key. For the people doing GitOps, there
> will be a need for layering a read-only baseline `cassandra.yaml` with
> environment-specific or secret files. This is exactly the way Argo CD/Helm
> handles value precedence. This is typical in cloud native environments. I
> propose a modification that allows an *opt-in* policy switch:
>
> duplicate_key_policy: { ABORT (default) | LAST_WINS | WARN }
>
> * ABORT  – current behaviour, startup fails on duplicates.
> * WARN   – duplicates allowed, last key wins, but every override is logged.
> * LAST_WINS – same as WARN, but without log
>
> On Mon, Jul 21, 2025 at 7:01 AM Josh McKenzie 
> 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  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
>>  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 
>> 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 requi

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Patrick McFadin]

Another hit from the DevOps request backlog. I'm glad this has
finally turned into something formal. This will make CI/CD much easier. One
thing I hope this fosters more of is the sharing of configs. For example,
"here are my recommended storage settings for EBS."

The CEP aborts on any duplicate key. For the people doing GitOps, there
will be a need for layering a read-only baseline `cassandra.yaml` with
environment-specific or secret files. This is exactly the way Argo CD/Helm
handles value precedence. This is typical in cloud native environments. I
propose a modification that allows an *opt-in* policy switch:

duplicate_key_policy: { ABORT (default) | LAST_WINS | WARN }

* ABORT  – current behaviour, startup fails on duplicates.
* WARN   – duplicates allowed, last key wins, but every override is logged.
* LAST_WINS – same as WARN, but without log

On Mon, Jul 21, 2025 at 7:01 AM Josh McKenzie  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  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
>  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 
> 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
>
>
>
>

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Josh McKenzie]

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

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Johnny Miller]

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

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Johnny Miller]

Another possible idea for this - we could support env variables on the
includes eg

include_if_exists: conf/environments/${ENVIRONMENT}.yaml

This would be quite useful I think?


On Fri, 18 Jul 2025 at 19:57, 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
>

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Josh McKenzie]

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

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Johnny Miller]

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

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Josh McKenzie]

That sounds useful to me.

I'd like to see us move to "modularized by default"; our current config being 
2839 lines of .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  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

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Johnny Miller]

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

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Josh McKenzie]

Looks great Johnny. I remain a +1. :)

On Mon, Jul 21, 2025, at 4:29 AM, Johnny Miller wrote:
> Thanks Josh - I have updated the unit tests and integration test requirements 
> to be more detailed with specific things to cover off. Let me know if there's 
> anything missing when you have a chance 👍
> 
> On Sat, 19 Jul 2025 at 20:18, Josh McKenzie  wrote:
>> __
>> +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
>>> > 
>>> 
>> 

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Johnny Miller]

Thanks Josh - I have updated the unit tests and integration test
requirements to be more detailed with specific things to cover off. Let me
know if there's anything missing when you have a chance 👍

On Sat, 19 Jul 2025 at 20:18, Josh McKenzie  wrote:

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

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Josh McKenzie]

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

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Jeff Jirsa]

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
> 

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Jeff Jirsa]

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
> 

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Jeff Jirsa]

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
> 

[DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

[Johnny Miller]

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