I think we can easily support a hybrid world where we can support legacy configuration safely while allowing new clusters from leveraging modern configuration. And eventually "switch" to only support the new configuration layout.
> 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 newconfigs? We can add a flag to override the default behavior of not parsing legacy configuration files, and use these on dtests. I added a new configuration layout proposal to < https://issues.apache.org/jira/browse/CASSANDRA-17292> that groups configurations by feature using simple nesting. Non-complete example on: < https://gist.github.com/pauloricardomg/4369f4b0dd8b84421a11ae61bf2d2c7e> This proposal allows new features to leverage the new configuration layout while supporting old configuration in the previous layout until we decide to do a "big bang" migration of old configurations to the new layout. Em ter., 22 de fev. de 2022 às 18:10, Ekaterina Dimitrova < e.dimitr...@gmail.com> escreveu: > 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! >> > >>> >> > >>> >> > >> >> >
