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
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 li
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
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
>
> Feature flag basically means "experimental"
I'm thinking of feature flags more as giving the power to operators to
decide what they do and don't allow users of the database access to. Even
if a feature is very stable and non-experimental, it can have negative
effects on other use-cases on a sh
I'm +1 on where it currently stands after the revisions. Consider resolving
out comment threads on the design doc that are closed so we can see if
there's any outstanding discussions from a high level?
~Josh
On Mon, Aug 30, 2021 at 1:14 AM Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wro
+1
On Thu, 2 Sept 2021 at 13:20, Mick Semb Wever wrote:
>
> Proposing the test build of in-jvm dtest API 0.0.9 for release.
>
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.9
>
> Candidate SHA:
> https://github.com/apache/cassandr
+1
On Thu, Sep 2, 2021 at 6:20 AM Mick Semb Wever wrote:
>
> Proposing the test build of in-jvm dtest API 0.0.9 for release.
>
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.9
>
> Candidate SHA:
> https://github.com/apache/cassand
Proposing the test build of in-jvm dtest API 0.0.9 for release.
Repository:
https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.9
Candidate SHA:
https://github.com/apache/cassandra-in-jvm-dtest-api/commit/aa25319c3e0f506d19383db31d2974a7f5c58ab8
tagge
>
> - New features, always with feature flag (added; happy to drop if
> controversial)
I believe that always having a feature flag for every new feature might be
too complicated in practice for different reasons.
Some new features might be low impact like new nodetool commands or new
virtual tabl
10 matches
Mail list logo
