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