You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "David Capwell (Jira)" <ji...@apache.org> on 2022/02/04 22:12:00 UTC
[jira] [Comment Edited] (CASSANDRA-17292) Move cassandra.yaml toward a nested structure around major database concepts
[ https://issues.apache.org/jira/browse/CASSANDRA-17292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487318#comment-17487318 ]
David Capwell edited comment on CASSANDRA-17292 at 2/4/22, 10:11 PM:
---------------------------------------------------------------------
for track warnings, I don't mind marking the field {{transient}} disabling it from the config layer, only exposing via JMX. I rather flesh this out and defer exposing track_warnings via configs than to release with a config we plan to rename the next release...
This ticket is to get agreement on what the structure should look like, and NOT move all configs to this structure... once we agree on the end goal we can refactor track_warnings (I +1 Caleb's proposal, query.local_read_size.abort_threshold is what I prefer strongly; grouping by feature makes the most sense to me, and how we mostly name our configs already... commitlog_directory vs commitlog.directory, commitlog_total_space vs commitlog.total_space... we already prefix configs with the feature...)
I am ok with guardrails choosing to go flat for the time being to unblock it...
was (Author: dcapwell):
for track warnings, I don't mind marking the field transient disabling it from the config layer, only exposing via JMX. I rather flesh this out and defer exposing track_warnings via configs than to release with a config we plan to rename the next release...
This ticket is to get agreement on what the structure should look like, and NOT move all configs to this structure... once we agree on the end goal we can refactor track_warnings (I +1 Caleb's proposal, query.local_read_size.abort_threshold is what I prefer strongly)
> 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/49e83c70eba3357978d1081ecf500bbbdee960d8
> 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org