You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Ekaterina Dimitrova (Jira)" <ji...@apache.org> on 2022/10/05 21:38:00 UTC
[jira] [Comment Edited] (CASSANDRA-17949) Update CCM post CASSANDRA-17379
[ https://issues.apache.org/jira/browse/CASSANDRA-17949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17613231#comment-17613231 ]
Ekaterina Dimitrova edited comment on CASSANDRA-17949 at 10/5/22 9:37 PM:
--------------------------------------------------------------------------
Most secure option in my mind is to revert the change I did to support the overloading between old and new parameters in CASSANDRA-15234 in the CCM repo and mass update the Python DTests to use the new names of parameters for v4.1+. (The if bigger than 4.1 use that name...) Then patch CCM if someone tries to change the default values of the new flags [~marcuse] added in CASSANDRA-17379 to emit error - "not supported in CCM the usage of {{{}-Dcassandra.allow_new_old_config_keys=true{}}}" We default to false in Cassandra 4.1+.
So in this case if we agree to the suggested approach we won't need to keep that mapping in CCM up to date which in general shouldn't be updated very often from now on but when it has to... I can easily see us forgetting and diverging in time.
I just already saw one parameter added recently missing in that map - repair_request_timeout. On the bright side if someone tries to use the overloading with that one (using old and new) it will simply not work and bump an error because we default to - {{-Dcassandra.allow_new_old_config_keys=false}}
I will leave this here until I gather additional input from interested parties in order to go one way or another with the implementation.
was (Author: e.dimitrova):
Most secure option in my mind is to revert the change I did to support the overloading between old and new parameters in CASSANDRA-15234 in the CCM repo and mass update the Python DTests to use the new names of parameters for v4.1+. (The if bigger than 4.1 use that name...) Then patch CCM if someone tries to change the default values of the new flags [~marcuse] added to emit error - "not supported in CCM the usage of {{{}-Dcassandra.allow_new_old_config_keys=true{}}}" We default to false in Cassandra 4.1+.
So in this case if we agree to the suggested approach we won't need to keep that mapping in CCM up to date which in general shouldn't be updated very often from now on but when it has to... I can easily see us forgetting and diverging in time.
I just already saw one parameter added recently missing in that map - repair_request_timeout. On the bright side if someone tries to use the overloading with that one (using old and new) it will simply not work and bump an error because we default to - {{-Dcassandra.allow_new_old_config_keys=false}}
I will leave this here until I gather additional input from interested parties in order to go one way or another with the implementation.
> Update CCM post CASSANDRA-17379
> -------------------------------
>
> Key: CASSANDRA-17949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17949
> Project: Cassandra
> Issue Type: Task
> Components: CI
> Reporter: Ekaterina Dimitrova
> Priority: Normal
>
> We updated in CASSANDRA-15234 CCM to enable it to handle overloading of parameters the way that SnakeYAML works. As we have matching and backward compatibility between old and new keys in 4.1 (look into this write up for more information [https://cassandra.apache.org/doc/4.1/cassandra/configuration/configuration.html).]
> This also allows us not to update for 4.1 the Python DTests but exercise the backward compatibility we have in C* in our tests.
> Now CASSANDRA-17379 added a few flags to opt in or out for overloading of parameters.
> The default points to -Dcassandra.allow_new_old_config_keys=false but this does not affect our tests as CCM handles the overloading in the yaml.
> But this is confusing for users and might lead to issues.
> We need to bring on par one way or another ccm with the new flags introduced in CASSANDRA-17379
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org