Hi,
I like the idea of having cassandra.yaml better structured, as an operator, my
primer concern is the transition. How would we change the config structure from
legacy to the new one during a rolling upgrade? My thoughts on this:
1. Legacy and new configuration is stored in different files. Cassandra will
read the legacy file on startup if it exists, the new one otherwise. May raise
warning on startup when legacy was used.
pros:
- separate files for separate formats
- clean and operator controlled switch to new format
- already known procedure, e.g. change from PropertyFileSnitch to
GossipingPropertyFileSnitch
cons:
- name of the config file would change from cassandra.yaml to something
else (cassandra_v2.yaml, config.yaml ???)
- would need considerable work to get config to the new format
- format translation not solved
2. Offline configuration converter tool may be available to convert legacy
format to new one. During package upgrade, if a legacy config is found, the
upgrade process should convert the config file to the new format.
pros:
- seamless upgrade process
- tool can be tested properly before
cons:
- may interact badly with configuration management tools controlling the
contents of cassandra.yaml
- poor transparency for operators
3. Cassandra could read both formats, may warn on startup when legacy format
found.
pros:
- no filename change
- operator controlled switch to new format
cons:
- higher complexity at implementation and testing
- format translation not solved
4. An online tool, e.g. nodetool command to export the configuration the
Cassandra node is currently running with, with filtering option to suppress
default settings.
pros:
- such a nodetool command would be useful independently from changing the
config format, could be added before and support any format
- the bare information is already available in system_views.settings
- could be combined with #1 or #3 to support the format translation
cons: ?
My favourite would be #3 + #4, while I would most dislike #2.
Tibor
> On 17. Feb 2022, at 23:13, Caleb Rackliffe <calebrackli...@gmail.com> wrote:
>
> Hey everyone,
>
> There has already been some Slack discussion
> <https://the-asf.slack.com/archives/CK23JSY2K/p1645033339547749> around this,
> but for anyone who doesn't follow that closely, I'd like to lobby more widely
> for my proposal in CASSANDRA-17292
> <https://issues.apache.org/jira/browse/CASSANDRA-17292> to eventually move
> cassandra.yaml toward a more nested structure.
>
> The proposal itself is here
> <https://github.com/maedhroz/cassandra/commit/450b920e0ac072cec635e0ebcb63538ee7f1fc5a>,
> and there has already been some inline discussion, but feel free to drop any
> feedback there, in the Jira, or here, depending on what you're most
> comfortable with.
>
> Given where we are in the lead-up to 4.1, I have no intention of pushing to
> adopt any of this for existing config in that release. However, what I think
> would be nice is if we could come to a rough consensus in time to inform work
> on new parameters, like those we're planning to add in CASSANDRA-17188
> <https://issues.apache.org/jira/browse/CASSANDRA-17188>.
>
> Thanks!
