m sure everyone is looking forward to the improved consistency of this
>> work.
>>
>>
>> From: Ekaterina Dimitrova
>> Date: Wednesday, 20 October 2021 at 22:27
>> To: dev@cassandra.apache.org
>> Subject: Re: [DISCUSS] CASSANDRA-15234
>> Hi everyone
s looking forward to the improved consistency of this
> work.
>
>
> From: Ekaterina Dimitrova
> Date: Wednesday, 20 October 2021 at 22:27
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] CASSANDRA-15234
> Hi everyone,
>
> I think it is time to summarize t
decisions.
I’m sure everyone is looking forward to the improved consistency of this work.
From: Ekaterina Dimitrova
Date: Wednesday, 20 October 2021 at 22:27
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CASSANDRA-15234
Hi everyone,
I think it is time to summarize the discussion.
First
ers getting an overall description. Even
> as a
> > developer who understands most of the toggles I found the old file very
> > hard to navigate.
> > >>
> > >> I also don’t see why we cannot have both heavily commented versions
> and
> > uncommented
why we cannot have both heavily commented versions and
> uncommented (or lightly commented) versions.
> >>
> >> I don’t personally see why multiple different config templates would be
> confusing if they’re in a suitably labelled directory, even if we settle on
> one for t
l user to need, so it’s
>> particularly easy to navigate.
>>
>>
>> From: Ekaterina Dimitrova
>> Date: Friday, 3 September 2021 at 14:40
>> To: dev@cassandra.apache.org
>> Subject: Re: [DISCUSS] CASSANDRA-15234
>>>>
>>>> It
ve a pared-down config that
> has only those properties we expect the normal user to need, so it’s
> particularly easy to navigate.
>
>
> From: Ekaterina Dimitrova
> Date: Friday, 3 September 2021 at 14:40
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] CASSANDRA-
:40
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CASSANDRA-15234
> >
> > 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 concer
ke 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 to
s 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.
. 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
> > Date: Thursday, 2
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
> Date: Thursday, 2 September 2021 at 16:32
> To: dev@cassandra.apache.org
> Subject: [DISCUSS] C
e. I’m
sure anything we settle on will be a huge improvement over the status quo,
however.
From: Ekaterina Dimitrova
Date: Thursday, 2 September 2021 at 16:32
To: dev@cassandra.apache.org
Subject: [DISCUSS] CASSANDRA-15234
Hi team,
I would like to bring to the attention of the community CAS
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
14 matches
Mail list logo
