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 <joe.e.ly...@gmail.com> wrote:
> On Wed, Nov 24, 2021 at 9:00 AM Bowen Song <bo...@bso.ng.invalid> 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 case. If the structured / nested config must
> > be introduced, I would like to see both syntaxes supported to allow the
> > user to make their own choice.
>
> To be clear, structured configuration was already adopted by Cassandra
> a long time ago and is already used successfully in the status quo
> (for example server/client encryption options, all of the pluggable
> class configurations). I believe the question was "when we are adding
> a number of related options should we structure them?". I think the
> answer is clearly yes because it makes the configuration code in the
> database a lot cleaner and allows us to leverage strongly typed
> configuration. Related configuration should continue to be grouped as
> if you were using a prefix of a dot encoded property (so {"a": {"b":
> 4}} is equivalent to "a.b: 4").
>
> There is the separate question of "how can an operator tell what
> configuration a node is running with" and for obvious reasons grepping
> cassandra.yaml is not a good public interface, we can do better via
> either virtual tables (JSON over CQL) or the sidecar (JSON over rest)
> that preserves the structured configuration rather than trying to
> flatten it.
>
> -Joey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
