Details
-
Improvement
-
Status: Open
-
Normal
-
Resolution: Unresolved
-
None
-
Operability
-
Normal
-
All
-
None
Description
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 on 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 & https://gist.github.com/pauloricardomg/4369f4b0dd8b84421a11ae61bf2d2c7e
Attachments
Issue Links
- is blocked by
-
CASSANDRA-17973 Change trunk 4.2 to 5.0
-
- Resolved
-
- relates to
-
CASSANDRA-17188 Guardrails for consistency levels
-
- Resolved
-
-
-
- Resolved
-
-
-
- Triage Needed
-
-
-
- Resolved
-
-
-
- Resolved
-