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
node.remote_c
Structured configuration was adopted for some options, but it is not
used in the cluster I manage with the only exception of seeds which is
already causing me a some headaches. If it keeps going down this road,
managing the cluster is going to be a lot harder without proper toolkits
(such as yq
The idea sounds great to me in principle - the only issue I see is:
> we promote a simple ticket everyday for a newcomer to pickup
During GSoC this year I had difficulty selecting "simple tickets for
newcomers to pickup" for the following reasons:
- inconsistency in LHF tagging (not many of the e
I like the idea, think it’s a great way to attract new comers.. ( newcomer
here)
On Wed, Nov 24, 2021 at 9:13 AM, Benjamin Lerer wrote:
> Hi everybody,
>
> I would like to take the occasion of the month of December and of the
> holiday seasons to attract new contributors and to create more visib
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:
>
Hi everybody,
I would like to take the occasion of the month of December and of the
holiday seasons to attract new contributors and to create more visibility
for the project.
I was thinking of creating some kind of Advent calendar on Twitter where we
promote a simple ticket everyday for a newcomer
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 thi
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:
track_warnin
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 stru
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 fi
😀 A list would be perfect. Thanks a lot Sharan!
We can discuss it on the cassandra-website channel. It is where we usually
talk about project promotion.
Le mer. 24 nov. 2021 à 11:13, Sharan Foga a écrit :
> Hi All
>
> I can help here and have access to some blog post style content. How do
> yo
Hi All
I can help here and have access to some blog post style content. How do you
want to organise it? I can get a list and then you can take a look through and
decide on the ones you want. Will that work?
Thanks
Sharan
On 2021/11/23 10:26:13 Benjamin Lerer wrote:
> Hi everybody,
>
> With Ch
13 matches
Mail list logo
