[
https://issues.apache.org/jira/browse/CASSANDRA-17292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17496752#comment-17496752
]
Stefan Miklosovic edited comment on CASSANDRA-17292 at 2/23/22, 1:23 PM:
-------------------------------------------------------------------------
I am just letting people know that I am about to merge this (1) (17220) where
config will look like this (2)
There will be grouped / nested startup_checks section. The (not so obvious)
advantage of what we did there is that if you want to introduce a new startup
check, you do not need to change anything configuration-related. We are parsing
the config into the map where key type of that map is an enum so in order to
include a new check, one has to just add a new entry into that enum type and
you are done. No change on configuration side about that in cassandra.yml.
(1) https://github.com/apache/cassandra/pull/1448
(2)
https://github.com/apache/cassandra/blob/165be5e596bee21bdc747ae740b72c14f0a8979a/conf/cassandra.yaml#L1624-L1643
was (Author: smiklosovic):
I am just letting people know that I am about to merge this (1) (17220)
There will be grouped / nested startup_checks section. The (not so obvious)
advantage of what we did there is that if you want to introduce a new startup
check, you do not need to change anything configuration-related. We are parsing
the config into the map where key type of that map is an enum so in order to
include a new check, one has to just add a new entry into that enum type and
you are done. No change on configuration side about that in cassandra.yml.
(1) https://github.com/apache/cassandra/pull/1448
> 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).
> 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
--
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
