> If there’s an “old compatible default” and “latest recommended settings”, when does the value in “old compatible default” get updated? Never?
How about replacing cassandra.yaml with cassandra_latest.yaml on trunk when cutting cassandra-6.0 branch? Any new default changes on trunk go to cassandra_latest.yaml. Basically major branch creation syncs cassandra_latest.yaml with cassandra.yaml on trunk, and default changes on trunk are added to cassandra_latest.yaml which will be eventually synced to cassandra.yaml when the next major is cut. On Wed, 14 Feb 2024 at 13:42 Jeff Jirsa <jji...@gmail.com> wrote: > 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 > > >
