[
https://issues.apache.org/jira/browse/CASSANDRA-17292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489080#comment-17489080
]
Caleb Rackliffe edited comment on CASSANDRA-17292 at 2/8/22, 7:39 PM:
----------------------------------------------------------------------
With CASSANDRA-15234 finally merged, I'm still planning on revamping my
previous attempts at a new config structure.
Our goals are the same here, i.e. to make the config more readable and
discoverable. There are good arguments for different axes in our nesting at the
global, feature, and sub-system level. Everything the database does touches
some resource(s), but it doesn't mean we have to frame every option in that
context. (Even if we did most things touch multiple resources.) There are
things like encryption, that we probably want to continue to group in features
space, although perhaps change slightly...
{noformat}
encryption:
# document general concerns for internode encryption, including how
parameters interact
internode:
...
# document general concerns for client encryption, including how parameters
interact
client:
...
{noformat}
...and things like network that end up being much lower/protocol level, and
might include things like protocol level back-pressure configuration...
{noformat}
network:
internode:
...
client:
...
{noformat}
...but not feature level limits, like the compaction backlog size at which we
abort streaming/repair.
We can have a more readable config than we have today without complete logical
consistency, especially if it affords us the opportunity to explain how the
options for individual features and subsystems work together in our inline
documentation. I'd like to start with an approach that favors feature grouping,
given that I think the majority of our config is amenable to that, but then
factor out pieces of that when and if it becomes the clearer option. (ex. It
could end up being the case that having all our threading/SEDA options under
one umbrella makes the most sense, and allows operators to think about CPU
usage more naturally.)
was (Author: maedhroz):
With CASSANDRA-15234 finally merged, I'm still planning on revamping my
previous attempts at a new config structure.
Our goals are the same here, i.e. to make the config more readable and
discoverable. There are good arguments for different axes in our nesting at the
global, feature, and sub-system level. Everything the database does touches
some resource(s), but it doesn't mean we have to frame every option in that
context. (Even if we did most things touch multiple resources.) There are
things like encryption, that we probably want to continue to group in features
space, although perhaps change slightly...
{noformat}
encryption:
internode:
...
client:
...
{noformat}
...and things like network that end up being much lower/protocol level, and
might include things like protocol level back-pressure configuration...
{noformat}
network:
internode:
...
client:
...
{noformat}
...but not feature level limits, like the compaction backlog size at which we
abort streaming/repair.
We can have a more readable config than we have today without complete logical
consistency, especially if it affords us the opportunity to explain how the
options for individual features and subsystems work together in our inline
documentation. I'd like to start with an approach that favors feature grouping,
given that I think the majority of our config is amenable to that, but then
factor out pieces of that when and if it becomes the clearer option. (ex. It
could end up being the case that having all our threading/SEDA options under
one umbrella makes the most sense, and allows operators to think about CPU
usage more naturally.)
> 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: [email protected]
For additional commands, e-mail: [email protected]
