Thanks for bringing this back up; Caleb and I were talking about the lack of clarity with regard to CASSANDRA-16896, fleshing this out would make those configs nicer!
> To standardize naming - that we did by agreeing to the form noun_verb If we can document this, it would be great as stuff like “enabled” are inconsistent so not sure if I did it properly =D > > Provision of values with units while maintaining backward compatibility. +1000000000000 I really hate local_read_size_threshold_kb; I would love local_read_size_threshold: 10kb. Once we have the infrastructure in place (believe your patch before had these tools) I would love to switch! > Another proposal is done by Benedict; grouping the config parameters. Yep, this is what triggered Caleb and I to talk about this thread! To group or not to group; that is the question Personally I like grouping from an organization point of view so am in favor of that; though I will agree that it can be hard for some tools (such as bash templating), but feel we can always find a common ground > On Sep 2, 2021, at 8:44 AM, bened...@apache.org wrote: > > Thanks for bringing this to the list Ekaterina! > > It’s worth noting that the two don’t have to be in conflict: we could offer > two template yaml with the parameters grouped differently, for users to > decide for themselves. > > The proposals primarily define parameter names differently, with my proposal > going by kind->place, and the other proposal maintaining (mostly) the > existing name form (which is a bit more like place->kind). While the example > yaml groups by kind, you can convert nested definitions into a ‘dot’ form > (e.g. limits.concurrency.reads) for use in a different grouping. > > One advantage of grouping parameters together is that it aids maintaining > coherency of naming between systems, and also potentially permits a more > succinct config file and better discovery. But it’s far from a silver bullet, > as value judgements have to be made about where the grouping lines are. I’m > sure anything we settle on will be a huge improvement over the status quo, > however. > > > > > From: Ekaterina Dimitrova <e.dimitr...@gmail.com> > Date: Thursday, 2 September 2021 at 16:32 > To: dev@cassandra.apache.org <dev@cassandra.apache.org> > Subject: [DISCUSS] CASSANDRA-15234 > Hi team, > > I would like to bring to the attention of the community CASSANDRA-15234, > standardise config and JVM parameters. > > This is work we discussed back in Summer 2020 just before our first 4.0 > Beta release. During the discussion we figured out that there is more than > one option to do the job and not enough time to get user feedback and > finish it so this was delayed post-4.0 And here I am, bringing it back to > the table. > > This work’s goal is: > > - > > To standardize naming - that we did by agreeing to the form noun_verb > - > > Provision of values with units while maintaining backward compatibility. > > > Those two parts are more or less already done. > > More interesting is the third part - reorganizing the cassandra.yaml file. > > My personal approach was to split it into sections, done here > <https://github.com/ekaterinadimitrova2/cassandra/blob/b4eebe080835da79d032f9314262c268b71172a8/conf/cassandra.yaml> > . > > Another proposal is done by Benedict; grouping the config parameters. > > To make it clearer, he created a yaml > <https://github.com/belliottsmith/cassandra/blob/5f80d1c0d38873b7a27dc137656d8b81f8e6bbd7/conf/cassandra_nocomment.yaml> > with comments mostly stripped. > > In his version, there are basic settings for network, disk etc all grouped > together, followed by operator tuneables mostly under limits within which > we now have throughput, concurrency, capacity. This leads to settings for > some features being kept separate (most notably for caching), but helps the > operator understand what they have to play with for controlling resource > consumption. > > I am interested to hear what people think about the two options or if > anyone has another idea to share, open discussion. > > Thank you, > > Ekaterina --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
