[ https://issues.apache.org/jira/browse/CASSANDRA-17292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495648#comment-17495648 ]
Paulo Motta edited comment on CASSANDRA-17292 at 2/21/22, 5:52 PM: ------------------------------------------------------------------- Migrating from the previous to the new configuration layout in the approach proposed above would be: * Decide what macro-categories to start with (ie. core.yaml, guardrails.yaml, features.yaml) * Assign existing properties to the corresponding macro-category "bucket" and group them in feature groups separated by a "section header". The above would already provide a good starting point for new features moving forward: * Any new feature must be added to {{features.yaml}} guarded by a feature-flag unless it's a core feature (must go on {{{}core.yaml{}}}) or a guardrail {{{}(must go on guardrails.yaml{}}}). After the new initial grouping is delivered, we can make incremental changes to the legacy properties via extraction and re-grouping while keeping most of other new configurations unchanged. was (Author: paulo): Migrating from the previous to the new configuration layout in the approach proposed above would be: * Decide what macro-categories to start with (ie. core.yaml, guardrails.yaml, features.yaml) * Assign existing properties to the corresponding macro-category "bucket" and group them in feature groups separated by a "section header". The above would already provide a good starting point for new features moving forward: * Any new feature must be added to {{features.yaml}} guarded by a feature-flag unless it's a core feature (must go on {{{}core.yaml{}}}) or a guardrail {{{}(must go on guardrails.yaml{}}}). After the new initial grouping is delivered, we can make incremental changes to the legacy categories via extraction and re-grouping while keeping most of other new configurations unchanged. > 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/450b920e0ac072cec635e0ebcb63538ee7f1fc5a > 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