[
https://issues.apache.org/jira/browse/CASSANDRA-17292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489133#comment-17489133
]
Caleb Rackliffe commented on CASSANDRA-17292:
---------------------------------------------
bq. I think the kind of examples I gave of logically inconsistent groupings,
and ambiguous or arbitrary terminology and groupings are bad, and perhaps worse
than what we have today (or at least not strictly better). I think if we want
to use these groupings, we need to give a lot more thought to the groupings to
make them more consistent and obvious.
I'm as much a fan or not obliterating the meaning of words as the next pedantic
native English speaker, but again, I think we can vastly improve things without
perfect logical consistency. Just to reiterate, I'm for whatever grouping and
nesting...
1.) ...gives us documentation points for important concepts in the database
inline in the YAML.
2.) ...makes it easier to build a set of domain objects in the configuration
handling code that enforce relationships between options, etc.
3.) ...colocates parameters operators will need to touch (or at least make not
of) to perform common operational tasks. (ex. As long as client encryption
parameters are colocated, I don't care if they ultimately fall under
{{encryption.client}}, if we feel encryption is a good top-level security
concern, or {{network.client.encryption}} if we want to think of it as a
sub-concern of the networking sub-system.)
> Move cassandra.yaml toward a nested structure around major database concepts
> ----------------------------------------------------------------------------
>
> Key: CASSANDRA-17292
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17292
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
> Reporter: Caleb Rackliffe
> Assignee: Caleb Rackliffe
> Priority: Normal
> Fix For: 5.x
>
>
> Recent mailing list conversation (see "[DISCUSS] Nested YAML configs for new
> features") has made it clear we will gravitate toward appropriately nested
> structures for new parameters in {{cassandra.yaml}}, but from the scattered
> conversation across a few Guardrails tickets (see CASSANDRA-17212 and
> CASSANDRA-17148) and CASSANDRA-15234, there is also a general desire to
> eventually extend this to the rest of {{cassandra.yaml}}. The benefits of
> this change include those we gain by doing it for new features (single point
> of interest for feature documentation, typed configuration objects, logical
> grouping for additional parameters added over time, discoverability, etc.),
> but one a larger scale.
> This may overlap with ongoing work, including the Guardrails epic. Ideally,
> even a rough cut of a design here would allow that to move forward in a
> timely and coherent manner (with less long-term refactoring pain).
> While these would have to be adjusted to CASSANDRA-15234 (probably after it
> merges), there have been two proposals floated already for what this might
> look like:
> From [~maedhroz] -
> https://github.com/maedhroz/cassandra/commit/49e83c70eba3357978d1081ecf500bbbdee960d8
> From [~benedict] -
> https://github.com/belliottsmith/cassandra/commits/CASSANDRA-15234-grouping-ideas
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
