[
https://issues.apache.org/jira/browse/CASSANDRA-17292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17496259#comment-17496259
]
Caleb Rackliffe commented on CASSANDRA-17292:
---------------------------------------------
[~paulo] Thanks for the
[proposal|https://gist.github.com/pauloricardomg/e9e23feea1b172b4f084cb01d7a89b05].
I've been able to give it and your comments a couple reads through, but before
I offer some feedback, a little diversion...
For a moment, let's ignore the fact that there's any kind of textual
configuration file at all for the project, but we still have all the
knobs/systems/etc. The very first thing I would do is create a "domain model"
for C* configuration on the Java side, a hierarchy rooted in a
{{Configuration}} container class, which would contain members w/ types like
{{ClusterConfiguration}}, {{NetworkConfiguration}}, {{StorageConfiguration}},
etc. These would be easy to navigate, would provide reasonable points for
inline documentation, could encapsulate validation logic for relationships
between parameters within subsystems and features, and could be passed as
little "kernels" of configuration around the codebase, allowing for better
mocking, etc.
With that configuration model in hand, we could then deal w/ the problem of its
mapping to and from some kind of human-readable format. In this case, something
like a nested YAML file (or it could be JSON, etc.) seems to be the best
option, in terms of its ease of use w/ tooling, its conceptual mapping, and
with even minimal care around naming, its human navigability/readability.
Predictably then, I'm still pretty strongly in support of a versioned but
intact single configuration file. I could imagine a synthesis of the two
proposals that would minimize the amount of potential bouncing between files
for operators trying to make sense of related configuration items, but simply
having multiple files worries me. Within the structure of the individual files,
I would also push for named hierarchies rather than relying on comments to
denote sections of related parameters. (This has been one of the primary
motivations behind moving toward a nested structure.)
bq. I think that the intermingling of feature/subsystem/resource in the yaml
structure can get a little counterintuitive and does not provide a consistent
framework for extending the properties.
This, however, is something I really want to dig into, because it echoes some
of the concerns [~benedict] has had about the current single-file approach
(although the most current iteration of it
[here|https://github.com/maedhroz/cassandra/commit/450b920e0ac072cec635e0ebcb63538ee7f1fc5a]
was specifically built to address some of those concerns and integrates even
future parameters like those we'll introduce in CASSANDRA-17148). Are there any
major inconsistencies you could expand on?
> 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]
