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 <jmcken...@apache.org> 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
> >
>
>
>

Reply via email to