[
https://issues.apache.org/jira/browse/CASSANDRA-17292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17496352#comment-17496352
]
Paulo Motta commented on CASSANDRA-17292:
-----------------------------------------
{quote}I think the main point of contention then is incremental vs.
non-incremental migration of existing configuration.
{quote}
I think we can support the new layout for new configurations added before 5.X.
For existing (legacy) configurations I see the following options:
a) Non-incrementally migrate all legacy properties to the new layout on 5.X
b) Incrementally migrate on 4.x while allowing users to opt-in to the new
configuration, and switch that to opt-out on 5.x.
I'm slightly in favor of b) due to splitting the work into bite-sized chunks
and making the new layout incrementally available earlier, but I'm also OK with
a).
{quote}I think the thought that's hard for me to escape around this is that we
really want a coherent design for the whole configuration up-front, given the
lack of one is at least partially to blame for the current mess.
{quote}
This is my main motivation for chiming in here with this feature-centric
proposal, since it allows anyone to pretty easily decide where a particular
configuration belongs using the following heuristic when adding a new
configuration option:
* Does this configuration belong to an existing {{{}FeatureConfiguration{}}}?
** If yes, add the new property to the existing {{{}FeatureConfiguration{}}}.
** If not, create a new {{FeatureConfiguration}} subclass for the particular
feature that you're adding.
No prior knowledge on the "domain model" is needed to use the heuristics above
when deciding where a configuration should go.
{quote}Then, if we have that, and we can work out whatever small
inconsistencies exist, we can present operators with a clean v2 config file
format in 5.0 (that requires us to do very little thinking about compatibility,
outside checking the version element).
{quote}
The migration of "legacy configuration" to the new feature-centric layout is
also straightforward using the same heuristics above, for whenever we decide to
perform a "big bang" switch to the new configuration layout.
> 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: [email protected]
For additional commands, e-mail: [email protected]
