+1 to not doing, imo, the ostrich lol
On 14/2/24 10:58, Jacek Lewandowski wrote:
We should not block merging configuration changes given it is a valid
configuration - which I understand as it is correct, passes all config
validations, it matches documented rules, etc. And this provided
latest config matches those requirements I assume.
The failures should block release or we should not advertise we have
those features at all, and the configuration should be named
"experimental" rather than "latest".
The config changes are not responsible for broken features and we
should not bury our heads in the sand pretending that everything is ok.
Thanks,
śr., 14 lut 2024, 10:47 użytkownik Štefan Miklošovič
<stefan.mikloso...@gmail.com> napisał:
Wording looks good to me. I would also put that into NEWS.txt but
I am not sure what section. New features, Upgrading nor
Deprecation does not seem to be a good category.
On Tue, Feb 13, 2024 at 5:42 PM 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
