[ 
https://issues.apache.org/jira/browse/CASSANDRA-17292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Caleb Rackliffe updated CASSANDRA-17292:
----------------------------------------
    Description: 
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 
on 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).

Current proposals:

>From [~benedict] - 
>https://github.com/belliottsmith/cassandra/commits/CASSANDRA-15234-grouping-ideas

>From [~maedhroz] - 
>https://github.com/maedhroz/cassandra/commit/450b920e0ac072cec635e0ebcb63538ee7f1fc5a

>From [~paulo] - 
>https://gist.github.com/pauloricardomg/e9e23feea1b172b4f084cb01d7a89b05 & 
>https://gist.github.com/pauloricardomg/4369f4b0dd8b84421a11ae61bf2d2c7e

  was:
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 
on 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).

Current proposals:

>From [~benedict] - 
>https://github.com/belliottsmith/cassandra/commits/CASSANDRA-15234-grouping-ideas

>From [~maedhroz] - 
>https://github.com/maedhroz/cassandra/commit/450b920e0ac072cec635e0ebcb63538ee7f1fc5a

>From [~paulo] - 
>https://gist.github.com/pauloricardomg/e9e23feea1b172b4f084cb01d7a89b05


> 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 on 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).
> Current proposals:
> From [~benedict] - 
> https://github.com/belliottsmith/cassandra/commits/CASSANDRA-15234-grouping-ideas
> From [~maedhroz] - 
> https://github.com/maedhroz/cassandra/commit/450b920e0ac072cec635e0ebcb63538ee7f1fc5a
> From [~paulo] - 
> https://gist.github.com/pauloricardomg/e9e23feea1b172b4f084cb01d7a89b05 & 
> https://gist.github.com/pauloricardomg/4369f4b0dd8b84421a11ae61bf2d2c7e



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to