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> 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> > 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! > > >
