I opened the following ticket for this:
https://issues.apache.org/jira/browse/CASSANDRA-18617
Thanks again,
Dan
On Fri, Jun 16, 2023 at 8:45 AM David Capwell wrote:
> Does this sound good?
>
>
> Sounds good to me
>
> On Jun 16, 2023, at 8:30 AM, Dan Jatnieks wrote:
>
> Hi all,
>
> Apologies
> Does this sound good?
Sounds good to me
> On Jun 16, 2023, at 8:30 AM, Dan Jatnieks wrote:
>
> Hi all,
>
> Apologies for the late reply; I didn't mean to start a thread and then
> disappear - it was unintended and I feel bad about that.
>
> I've been taking notes to summarize the discussio
Hi all,
Apologies for the late reply; I didn't mean to start a thread and then
disappear - it was unintended and I feel bad about that.
I've been taking notes to summarize the discussion points and it matches
what Andres already listed, so I'm glad for that. And thank you Andres for
doing that -
> I was following the discussion. What Andres just summarized sounds reasonable
> to me. Let’s just not forget to document also all this.
+1 here. Maybe also add a warning to the log to let users know we subtracted
system tables from that count since they used the old param and try and point
the
Hi all,
I was following the discussion. What Andres just summarized sounds
reasonable to me. Let’s just not forget to document also all this.
Thank you
Ekaterina
On Fri, 16 Jun 2023 at 10:16, Andrés de la Peña
wrote:
> It seems we agree on removing the default value for the old thresholds,
> and
It seems we agree on removing the default value for the old thresholds, and
don't count system keyspaces/tables on the new ones.
The old thresholds were on active duty for around ten months, and they have
been deprecated for around a year. They will have been deprecated for
longer by the time we r
> That's problematic because the new thresholds we added in CASSANDRA-17147
> don't include system tables. Do you think we should change that?
I wouldn’t change the semantics of the config as it’s already live. I guess
where I am coming from is that logically we have to think about the system
> In my opinion including system tables defeats that purpose because it forces
> users to know details about the system tables.
Perhaps having a unit test that caps our system tables at some value and
keeping the guardrail user-scope specific would be a better approach. I see
your point about le
>
> > Default value I agree with you; features should be off by default! If
> we remove the default then we disable the feature by default (which im cool
> with) and for anyone who changed the config, they would keep their behavior
I'm glad we agree on at least removing the default value if we k
> Warning that too many tables (including system) may have negative behavior I
> think is fine
This reminds me of the current situation with our tests where we just keep
adding more and more without really considering the value of the current set
and the costs of that body of work as it keeps gr
> I think that the combined decision of using a default value and counting
> system tables was a mistake
Default value I agree with you; features should be off by default! If we
remove the default then we disable the feature by default (which im cool with)
and for anyone who changed the config
Indeed "keyspace_count_warn_threshold" and "table_count_warn_threshold"
include system keyspaces and tables. Also, differently to the newer
guardrails, they are enabled by default.
I find that problematic because users need to know how many system
keyspaces/tables there are to know if they need to
> Have we been dropping support entirely for old params or using the @Replaces
> annotation into perpetuity?
My understanding is that the goal is to keep things around in perpetuity unless
it actively causes us harm… and with @Replaces, there tends to be no harm to
keep around…
Looking at
ht
> have subsequently been deprecated since 4.1-alpha in CASSANDRA-17195 when
> they were replaced/migrated to guardrails as part of CEP-3 (Guardrails).
Have we been dropping support entirely for old params or using the @Replaces
annotation into perpetuity?
I dislike the idea of operators having t
Hello everyone,
I would like to propose removing the non-guardrail thresholds
'keyspace_count_warn_threshold' and 'table_count_warn_threshold'
configuration settings on the trunk branch for the next major release.
These thresholds were first added with CASSANDRA-16309 in 4.0-beta4 and
have subseq
15 matches
Mail list logo
