[
https://issues.apache.org/jira/browse/CASSANDRA-18753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757406#comment-17757406
]
Stefan Miklosovic edited comment on CASSANDRA-18753 at 8/22/23 12:20 PM:
-------------------------------------------------------------------------
to answer to [~adelapena] to his last comment, this is a good insight. I think
that users would need to be aware of the fact that this would be just for
"evaluation purposes" and if they are going to upgrade to the next major it
(probably) wont work ...
Another question I have is - how can we ensure that these two configuration
files are synchronized? What I mean by that is that if we introduce a new
configuration parameter to the "official yaml", everytime we do that we also
need to update the "optimal" one? I can imagine this will be out of sync in one
month :)
was (Author: smiklosovic):
to answer to [~adelapena] to his last comment, this is a good insight. I think
that users would need to be aware of the fact that this would probably be just
for "evaluation purposes" and if they are going to upgrade to next major it
will probably wont work ...
Another question I have is - how can we ensure that these two configuration
files are synchronized? What I mean by that is that if we introduce a new
configuration parameter to the "official yaml", everytime we do that we also
need to update the "optimal" one? I can imagine this will be out of sync in one
month :)
> We should offer an option for optimized default configuration
> -------------------------------------------------------------
>
> Key: CASSANDRA-18753
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18753
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
> Reporter: Branimir Lambov
> Priority: Normal
>
> We currently offer only one sample configuration file with Cassandra, and
> that file is deliberately configured to disable all new functionality and
> incompatible improvements. This works well for legacy users that want to have
> a painless upgrade, but is a very bad choice for new users, or anyone wanting
> to make comparisons between Cassandra versions or between Cassandra and other
> databases.
> We offer very little indication, in the database packaging itself, that there
> are well-tested configuration choices that can solve known problems and
> dramatically improve performance. This is guaranteed to paint the database in
> a worse light than it deserves, and will very likely hurt adoption.
> We should find a way to offer a very easy way of choosing between "optimized"
> and "compatible" defaults. At minimal, we could provide alternate yaml files.
> Alternatively, we could build on the {{storage_compatibility_mode}} concept
> to grow it into a setting that not only enables/disables certain settings,
> but also changes their default values.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
