[
https://issues.apache.org/jira/browse/CASSANDRA-17292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487371#comment-17487371
]
Benedict Elliott Smith commented on CASSANDRA-17292:
----------------------------------------------------
bq. I am ok with guardrails choosing to go flat for the time being to unblock
it...
+1
bq. query.local_read_size.abort_threshold
I'm strongly -1 (in sentiment, not in a veto sense) any grouping that isn't
fairly obvious or consistent about what should be contained within, and I have
no idea what should go under the {{query}} heading. How do we decide what is
considered a {{query}} option and what is not?
Some general notes:
- Should concurrent_reads, writes etc be grouped?
- There is confusion about where to put materialised view settings, and their
concurrent_read/write settings. Some go under MVs, compaction, and global, and
currently it is seemingly inconsistent.
- Streaming also has compaction limits (particularly concurrent_validators, but
arguably also the bandwidth)
- Should we use {{internode}} and {{native_transport}} terminology? They're
very core developer focused, and not very user friendly. Perhaps
{{cluster_network}} and {{client_network}}?
> 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: [email protected]
For additional commands, e-mail: [email protected]
