Glad to be agree on #4. That feature could be add anytime. If a version element is added to the YAML, then it is not necessary to change the filename, thus we could end up with #3. The value of the version element could default to 1 in the first phase, which does not need any change for legacy format configuration. New config format must include version: 2. When in some later version the support for legacy configuration is removed, the default for the version element could be changed to 2 or removed.
> On 22. Feb 2022, at 19:30, Caleb Rackliffe <calebrackli...@gmail.com> wrote: > > My initial preference would be something like combining #1 and #4. We could > add something like a simple "version: <1|2>" element to the YAML that would > eliminate any possible confusion about back-compat within a given file. > > Thanks for enumerating these! > > On Tue, Feb 22, 2022 at 10:42 AM Tibor Répási <tibor.rep...@anzix.org > <mailto:tibor.rep...@anzix.org>> wrote: > 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 >> <mailto: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! >
