> 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 https://github.com/apache/cassandra/commit/bae92ee139b411c94228f8fd5bb8befb4183ca9f we just marked them deprecated and created a brand new config that matched the old… which I feel was a bad idea…. Renaming configs are fine with @Replaces, but asking users to migrate with the idea of breaking them in the future is bad… The table_count_warn_threshold config is used at org.apache.cassandra.cql3.statements.schema.CreateTableStatement#clientWarnings The tables_warn_threshold config is used at org.apache.cassandra.cql3.statements.schema.CreateTableStatement#validate The only difference I see is that table_count_warn_threshold includes system tables where as tables_warn_threshold is only user tables… > 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. Deprecate in 4.1 is way too new for me to accept that, and its low effort to keep; breaking users is always a bad idea and doing it when not needed is bad… Honestly, I don’t see why we couldn’t use @Replaces here to solve the semantic gap… table_count_warn_threshold includes the system tables, so we just need a Converter that takes w/e the value the user put in and subtracts the system tables… which then gives us the user tables (matching tables_warn_threshold) > On Jun 13, 2023, at 7:57 AM, Josh McKenzie <jmcken...@apache.org> wrote: > >> 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 to remember to update things between > versions and being surprised when things change roughly equally to us > carrying along undocumented deprecated param name mapping roughly equally. :) > > On Mon, Jun 12, 2023, at 5:56 PM, Dan Jatnieks wrote: >> 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 >> subsequently been deprecated since 4.1-alpha in CASSANDRA-17195 when they >> were replaced/migrated to guardrails as part of CEP-3 (Guardrails). >> >> I'd appreciate any thoughts about this. I will open a ticket to get started >> if there is support for doing this. >> >> Reference: >> https://issues.apache.org/jira/browse/CASSANDRA-16309 >> https://issues.apache.org/jira/browse/CASSANDRA-17195 >> CEP-3: Guardrails >> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-3%3A+Guardrails >> >> >> Thanks, >> Dan Jatnieks
