changes
> >
> > Thank you
> > Ekaterina
> >
> > On Tue, 30 Nov 2021 at 8:59, bened...@apache.org
> > wrote:
> >
> >> I mean that it has been waiting for months, is ready to go, and I don’t
> >> want to hold you up any longer.
> >>
ls, verbs/nouns, and specific terms
>>> (period, abort, limit, datacenter vs dc, etc), but ideally we would have
>> a
>>> common end goal for the config file.
>>>
>>>> leave non-features to CASSANDRA-15234
>>>
>>> IMO 15234 has sailed – it’s bee
13:44
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] Nested YAML configs for new features
> “
> IMO 15234 has sailed – it’s been held up for a long time, and was brought
> to this list for discussion with no engagement. Ekaterina is long overdue
> being able to commit her w
I mean that it has been waiting for months, is ready to go, and I don’t want to
hold you up any longer.
From: Ekaterina Dimitrova
Date: Tuesday, 30 November 2021 at 13:44
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Nested YAML configs for new features
“
IMO 15234 has sailed – it’s been
long overdue
> being able to commit her work.
>
>
> From: David Capwell
> Date: Monday, 29 November 2021 at 23:44
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] Nested YAML configs for new features
> > but I would hate to repeat the mistakes of our past by evolving t
t, but settling on some approximate
> scheme would be helpful IMO.
>
> From: David Capwell
> Date: Monday, 29 November 2021 at 20:38
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] Nested YAML configs for new features
>> What should our default example cassandra.yaml
> scheme would be helpful IMO.
>
> From: David Capwell
> Date: Monday, 29 November 2021 at 20:38
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] Nested YAML configs for new features
>> What should our default example cassandra.yaml file use (flat or nested)?
>>
/cassandra_nocomment.yaml
I don’t have any specific attachment to it, but settling on some approximate
scheme would be helpful IMO.
From: David Capwell
Date: Monday, 29 November 2021 at 20:38
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Nested YAML configs for new features
> What should our default exam
aim to provide users all the facilities they need to
>> interact with config via vtables. If the user requires external tooling, it
>> suggests a weakness in CQL that we should address, and maybe help the user
>> in other scenario too…
>>
>> From: Joseph Lynch
&g
ynch
> Date: Monday, 29 November 2021 at 17:32
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] Nested YAML configs for new features
> On Mon, Nov 29, 2021 at 11:51 AM bened...@apache.org
> wrote:
>>
>> Maybe we can make our query language more expressive
>
021 at 17:32
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Nested YAML configs for new features
On Mon, Nov 29, 2021 at 11:51 AM bened...@apache.org
wrote:
>
> Maybe we can make our query language more expressive
>
> We might anyway want to introduce e.g. a LIKE filtering op
On Mon, Nov 29, 2021 at 11:51 AM bened...@apache.org
wrote:
>
> Maybe we can make our query language more expressive
>
> We might anyway want to introduce e.g. a LIKE filtering option to
> find/discover flattened config parameters?
This sounds more complicated than just having the settings
roduce e.g. a LIKE filtering option to
> find/discover flattened config parameters?
>
> From: Benjamin Lerer
> Date: Monday, 29 November 2021 at 16:41
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] Nested YAML configs for new features
> >
> > I don’t think it’s nec
e.
> >>
> >> So whatever design we employ here, we should IMO be aiming for it to be
> >> compatible with a CQL representation also.
> >>
> >>
> >> From: Bowen Song
> >> Date: Wednesday, 24 November 2021 at 18:15
> >> To:dev
ld like to see
> a
> >> similar hierarchy for Keyspace, Table and Per-Query options. Ideally
> only
> >> the barest minimum number of options would be necessary to supply in a
> >> config file, and only on first launch – seed nodes, for instance.
> >>
> &
be aiming for it to be
compatible with a CQL representation also.
From: Bowen Song
Date: Wednesday, 24 November 2021 at 18:15
To:dev@cassandra.apache.org
Subject: Re: [DISCUSS] Nested YAML configs for new features
Since you mentioned ElasticSearch, I'm actually pretty happy with their
config file
@cassandra.apache.org
Subject: Re: [DISCUSS] Nested YAML configs for new features
I do not think that supporting both options is an issue. The settings
virtual table would have to use the flattened version.
If we support both formats, the question would be: what should be the one
used by default in the configuration
be
> compatible with a CQL representation also.
>
>
> From: Bowen Song
> Date: Wednesday, 24 November 2021 at 18:15
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] Nested YAML configs for new features
> Since you mentioned ElasticSearch, I'm actually pretty happy
Since you mentioned ElasticSearch, I'm actually pretty happy with their
config file syntax. It allows the user to completely flatten out the
entire config file. To give people who isn't familiar with ElasticSearch
an idea, here is a config file we use:
cluster.name: foobar
We still have yq, mentioned a couple of posts earlier which does even more
than grep, so i suppose it could satisfy both camps :)
- - -- --- - -
Jacek Lewandowski
On Wed, Nov 24, 2021 at 6:13 PM Joseph Lynch wrote:
> On Wed, Nov 24, 2021 at 9:00 AM Bowen Song wrote:
On Wed, Nov 24, 2021 at 9:00 AM Bowen Song wrote:
> Structured / nested config is easier for human eyes to read but very
> hard for simple scripts to handle. Flat config is harder for human eyes
> but easy for simple scripts. I can see user may prefer one over another
> depending on their own use
It only works if the output is for human to read. If you have a large
number of servers, very often you want to do "grep -q ... &&
other_command" (or || other_command), or chaining the grep results frin
parallel-ssh into another command (grep or sort). The -A/-B/-C switches
will not work in
Grepping is an important use case, and having worked with another database
that does nest its configs, I can offer some tips how I survived:
With good old grep, it can help to use the before and after options:
grep -A 5 track_warnings | grep -B 5 warn_threshold
Would find you this:
On Wed, Nov 24, 2021 at 5:55 AM Jacek Lewandowski
wrote:
>
> I am just wondering how to represent in properties things like lists of
> non-scalar values?
>
In my experience properties are not sufficient for complex
configuration sorta for this reason, that's why using structured YAML
(or any
I am just wondering how to represent in properties things like lists of
non-scalar values?
- - -- --- - -
Jacek Lewandowski
On Mon, Nov 22, 2021 at 5:16 PM Joseph Lynch wrote:
> Isn't one of the primary reasons to have a YAML configuration instead
> of a properties
Isn't one of the primary reasons to have a YAML configuration instead
of a properties file is to allow typed and structured (implies nested)
configuration? I think it makes a lot of sense to group related
configuration options (e.g. a feature) into a typed class when we're
talking about more than
I do not have a strong opinion for one or the other but wanted to raise the
issue I see with the "Settings" virtual table.
Currently the "Settings" virtual table converts nested options into flat
options using a "_" separator. For those options it allows a user to query
the all set of options
> it is really handy to grep
> cassandra.yaml on some config key and you know the value instantly.
You can still do that
$ grep -A2 coordinator_read_size conf/cassandra.yaml
# coordinator_read_size:
# warn_threshold_kb: 0
# abort_threshold_kb: 0
I was also arguing we should
> With the flat structure it turns into properties file - would it be
> possible to support both formats - nested yaml and flat properties?
For majority of our configs yes, but there are a subset where flat properties
is annoying
hinted_handoff_disabled_datacenters - set type, so you could do
With the flat structure it turns into properties file - would it be
possible to support both formats - nested yaml and flat properties?
- - -- --- - -
Jacek Lewandowski
On Fri, Nov 19, 2021 at 10:08 PM Caleb Rackliffe
wrote:
> If it's nested, "track_warnings" would
I'm on record as early as the comments in CASSANDRA-15234 in support of
nesting, and I think the biggest reason is that the structure it forces on
our config makes it more cohesive and intelligible to those trying to
understand how major features and subsystems work together. It's very easy
to
If it's nested, "track_warnings" would still work if you're grepping around
vim or less.
I'd have to concede the point about grep output, although there are tools
like https://github.com/kislyuk/yq that could probably be bent to do what
you want.
On Fri, Nov 19, 2021 at 1:08 PM Stefan Miklosovic
I'm with Stefan. I prefer the flat YAML file which I can easily use grep
to check and confirm the settings on large number of servers with
parallel-ssh. This will be very hard to do on nested config in a YAML file.
In addition to that, I also use grep in the Cassandra source code to
locate
In org.apache.cassandra.config.YamlConfigurationLoader (and anything working on
translation of configs to flat structures), we can detect this pattern and
recursively get the field (similar to walking directories); main change would
be in
34 matches
Mail list logo
