[
https://issues.apache.org/jira/browse/CASSANDRA-17292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17496332#comment-17496332
]
Caleb Rackliffe commented on CASSANDRA-17292:
---------------------------------------------
bq. The basic construct to create new feature configurations is the following
class:
bq. For example this is how "HintsConfiguration" would look like:
bq. And would be represented as following on cassandra.yaml:
Gotcha. I don't think we'd be too far apart on any of that once we get into
implementation space.
I think the main point of contention then is incremental vs. non-incremental
migration of _existing_ configuration. (I emphasize "existing", because we have
the opportunity to do new things like CASSANDRA-17148 without having to change
it later if we have a coherent design for it to ultimately fit into. Having a
small section of the config in the same format between v1 and v2 isn't really a
problem.) There was actually a Slack thread about this very recently
[here|https://the-asf.slack.com/archives/CK23JSY2K/p1645049135928759]. 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. 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).
> 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]
