[
https://issues.apache.org/jira/browse/CASSANDRA-18753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794632#comment-17794632
]
Jacek Lewandowski commented on CASSANDRA-18753:
-----------------------------------------------
Maybe we can refactor testing a bit (I don't insist on this ticket, but for 5.0
at least). My point is that if we decide to modify something in say latest
configuration, the change will have be carefully applied to:
- the main configuration file
- the lastest diff file for testing
- the dtest configuration
I think this is error prone and it will be easy to oversee something. One more
place which was overlooked in this PR I think is {{UnitConfigOverride}} which
is used for the new fuzz tests.
To add to that, testing stuff in IDE with a particular configuration was a pain
so far, it is not going to get better with this change.
I'd like to propose something:
- have a class which provides config overrides as a simple map for different
configurations
- have an Ant task which takes either main cassandra.yaml or latest
cassandra.yaml and apply overrides on it, and then generates a final
configuration yaml
- don't use test/conf/cassandra.yaml - we should base on the main
cassandra/latest.yaml and only change what we need
- the same overrides can be used for all kinds of unit and distributed tests
and the configuration can be easily generated any time for any tool
- when we want to run a test with a certain configuration, we can simply add
one statement in static initializer which will generate the configuration, save
it somewhere and set the config property URL
I do think we should apply a similar approach for system properties
CASSANDRA-19126 shows some problems related to this
cc [~dcapwell]
> Add an optimized default configuration to tests and make it available for new
> users
> -----------------------------------------------------------------------------------
>
> Key: CASSANDRA-18753
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18753
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
> Reporter: Branimir Lambov
> Assignee: Branimir Lambov
> Priority: Urgent
> Fix For: 5.0-rc, 5.x
>
> Attachments:
> CCM_Add_support_for_specifying_the_name_of_the_file_to_use_as_cassandra_YAML_.patch,
>
> DTEST_Add_support_for_specifying_the_name_of_the_file_to_use_as_cassandra_YAML_.patch
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> 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
