1) If there’s an “old compatible default” and “latest recommended settings”, when does the value in “old compatible default” get updated? Never? 2) If there are test failures with the new values, it seems REALLY IMPORTANT to make sure those test failures are discovered + fixed IN THE FUTURE TOO. If pushing new yaml into a different file makes us less likely to catch the failures in the future, it seems like we’re hurting ourselves. Branimir mentions this, but how do we ensure that we don’t let this pattern disguise future bugs?
> On Feb 13, 2024, at 8:41 AM, Branimir Lambov <blam...@apache.org> wrote: > > Hi All, > > CASSANDRA-18753 introduces a second set of defaults (in a separate > "cassandra_latest.yaml") that enable new features of Cassandra. The objective > is two-fold: to be able to test the database in this configuration, and to > point potential users that are evaluating the technology to an optimized set > of defaults that give a clearer picture of the expected performance of the > database for a new user. The objective is to get this configuration into 5.0 > to have the extra bit of confidence that we are not releasing (and > recommending) options that have not gone through thorough CI. > > The implementation has already gone through review, but I'd like to get > people's opinion on two things: > - There are currently a number of test failures when the new options are > selected, some of which appear to be genuine problems. Is the community okay > with committing the patch before all of these are addressed? This should > prevent the introduction of new failures and make sure we don't release > before clearing the existing ones. > - I'd like to get an opinion on what's suitable wording and documentation for > the new defaults set. Currently, the patch proposes adding the following text > to the yaml (see https://github.com/apache/cassandra/pull/2896/files): > # NOTE: > # This file is provided in two versions: > # - cassandra.yaml: Contains configuration defaults for a "compatible" > # configuration that operates using settings that are > backwards-compatible > # and interoperable with machines running older versions of Cassandra. > # This version is provided to facilitate pain-free upgrades for existing > # users of Cassandra running in production who want to gradually and > # carefully introduce new features. > # - cassandra_latest.yaml: Contains configuration defaults that enable > # the latest features of Cassandra, including improved functionality as > # well as higher performance. This version is provided for new users of > # Cassandra who want to get the most out of their cluster, and for users > # evaluating the technology. > # To use this version, simply copy this file over cassandra.yaml, or > specify > # it using the -Dcassandra.config system property, e.g. by running > # cassandra > -Dcassandra.config=file:/$CASSANDRA_HOME/conf/cassandra_latest.yaml > # /NOTE > Does this sound sensible? Should we add a pointer to this defaults set > elsewhere in the documentation? > > Regards, > Branimir
