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 <pmcfa...@gmail.com> 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 <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
>>
>>
>>
>>
