DTests are one side but to be clear, the main reason for backward compatibility to be introduced in 15234 were not the tests but the users. That was a very clear requirement and in my mind this work also intends to have some backward compatibility? No? But DTests and even in-jvm are quite a valid concern!
I am +1 to what Jeremiah said that Ideally we need to see new version/layout/format introduced at once. As I said before, I wouldn’t recommend to start adding new config as per the future version potential work now so we don’t change config twice. I find this confusing, even if I understand that the intention to make this was not to have to change new config soon. But in my mind it is about the bigger picture and not about small bites. On the other hand, if there is backward compatibility and new and old config file (I like the idea of v1, v2, etc) then It shouldn’t be a concern to change those new parameters in next version. I fear that otherwise we might get into confusion for both our users and our contributors. Also, I suspect we will have the old one still compatible but only the new one in-tree for new development? On Tue, 22 Feb 2022 at 15:53, Stefan Miklosovic < stefan.mikloso...@instaclustr.com> wrote: > I want to add that to, however, on the other hand, we also do have > dtests in Python and they need to run with old configs too. That is > what Ekaterina was doing - supporting old configuration while > introducing new one. If we make "a big cut" and old way of doing > things would not be possible, how are we going to treat this in dtests > when we will have stuff for 3.11, 4 on old configs and 5 on new > configs? > > On Tue, 22 Feb 2022 at 21:48, Stefan Miklosovic > <stefan.mikloso...@instaclustr.com> wrote: > > > > +1 to what Patrick says. > > > > On Tue, 22 Feb 2022 at 21:40, Patrick McFadin <pmcfa...@gmail.com> > wrote: > > > > > > I'm going to put up a red flag of making config file changes of this > scale on a dot release. This should really be a 5.0 consideration. > > > > > > With that, I would propose a #5. 5.0 nodes will only read the new > config files and reject old config files. If any of you went through the > config file changes from Apache HTTPd 1.3 -> 2.0 you know how much of a > lifesaver that can be for ops. Make it a part of the total upgrade to a new > major version, not a radical change inside of a dot version, and make it a > clean break. No "legacy config" laying around. That's just a recipe for > surprises later if there are new required config values and somebody > doesn't even realize they have some old 4.x yaml files laying around. > > > > > > Patrick > > > > > > On Tue, Feb 22, 2022 at 11:51 AM Tibor Répási <tibor.rep...@anzix.org> > wrote: > > >> > > >> 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> > 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 around this, but for > anyone who doesn't follow that closely, I'd like to lobby more widely for > my proposal in CASSANDRA-17292 to eventually move cassandra.yaml toward a > more nested structure. > > >>> > > >>> The proposal itself is here, 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. > > >>> > > >>> Thanks! > > >>> > > >>> > > >> >
