> > at this point we shouldn’t be comparing the length of the files I think as > the comments were stripped only for the POC
Ah - my misunderstanding then. I assumed we were relying on the local context of the grouping to provide insight into the functionality of parameters and removed the comments to that end; my point does not stand. :) Re: multiple options of .yaml files, having to update multiple .yaml template files on addition of new features or params will be another spot for human error but we can do some simple build-time checking of that to ensure the files stay in sync. On Fri, Sep 3, 2021 at 9:39 AM Ekaterina Dimitrova <e.dimitr...@gmail.com> wrote: > > > > > > 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. > > Sure, my only concern is that three versions of the yaml could bring > confusion (we will have backward compatibility to the current one for some > time). But it might be only me. I am open for feedback > > > > If we can document this, it would be great as stuff >like “enabled” are > > inconsistent so not sure if I did it properly =D > > > Well, this is for now only in the ticket in the first version but no one > raised any concern. We will definitely have to update our docs on this and > whatever else we came to agreement on - both for users and contributors. > > >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 > Valid point and I believe it is one of the reasons we delayed the ticket, > in order to get feedback on that. I am really interested to hear what > concerns people might have. > > > >Opening up a 1500+ line .yaml file is very daunting, >even if most of it > is > >comments. Can't blame folks for being >overwhelmed at the prospect of > tuning > >Cassandra w/that as our operator config API. :) > I am all in for simplification and to make our users’ lives easier. But at > this point we shouldn’t be comparing the length of the files I think as the > comments were stripped only for the POC. I guess many of them will get back > in the actual doc version unfortunately. > > Thank you all, > Ekaterina > > On Thu, 2 Sep 2021 at 20:07, Joshua McKenzie <jmcken...@apache.org> wrote: > > > Reading through the two, the grouping approach seems like it's a lot more > > friendly to newcomers as well as providing context specific cues for > > relationships between params you're editing. Showing and not telling, if > > you will. > > > > Opening up a 1500+ line .yaml file is very daunting, even if most of it > is > > comments. Can't blame folks for being overwhelmed at the prospect of > tuning > > Cassandra w/that as our operator config API. :) > > > > ~Josh > > > > On Thu, Sep 2, 2021 at 1:48 PM David Capwell <dcapw...@apple.com.invalid > > > > wrote: > > > > > 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 > > > > > > > > >
