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/09/19 14:11:00 UTC
[jira] [Comment Edited] (CASSANDRA-17904) Consider to not warn about deprecated properties in logs when the value is not deprecated
[ https://issues.apache.org/jira/browse/CASSANDRA-17904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606614#comment-17606614 ]
Ekaterina Dimitrova edited comment on CASSANDRA-17904 at 9/19/22 2:10 PM:
--------------------------------------------------------------------------
Slept on it and had some discussion with [~marcuse] and [~dcapwell] about those three parameters as I was wondering whether we missed to take some action around them when we added the new flags - _allow_duplicate_config_keys_ and _allow_new_old_config_keys_ in CASSANDRA-17379
The key names haven't been changed so we technically didn't deprecate the three properties but we added an option to be able to add value both in numeric and numeric+unit format.
The fix should be to make those not deprecated in the Replaces annotation. I will add it soon. Also, I plan to add quick additional note in the config docs to remind people that _allow_duplicate_config_keys_ is the only way to not be able to add that property more than once with both formats; Those three are a special case that is already mentioned in the docs but I think it will be nice to stress on them when talking about the flags.
I will push a patch soon, thanks
was (Author: e.dimitrova):
Slept on it and had some discussion with [~marcuse] and [~dcapwell] about those three parameters as I was wondering whether we missed to take some action around them when we added the new flags - _allow_duplicate_config_keys_ and _allow_new_old_config_keys_ in CASSANDRA-17379
The key names haven't been changed so we technically didn't deprecate the three properties but we added an option to be able to add value both in numeric or numeric+unit format.
The fix should be to make those not deprecated in the Replaces annotation. I will add it soon. Also, I plan to add quick additional note in the config docs to remind people that _allow_duplicate_config_keys_ is the only way to not be able to add that property more than once with both formats; Those three are a special case that is already mentioned in the docs but I think it will be nice to stress on them when talking about the flags.
I will push a patch soon, thanks
> Consider to not warn about deprecated properties in logs when the value is not deprecated
> -----------------------------------------------------------------------------------------
>
> Key: CASSANDRA-17904
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17904
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
> Reporter: Stefan Miklosovic
> Assignee: Ekaterina Dimitrova
> Priority: Low
> Fix For: 4.1-rc, 4.x
>
>
> When there is an initialisation of database descriptor for tools, for example via "Util.initDatabaseDescriptor()", it will eventually buble up to "YamlConfigurationLoader.check" where this is logged:
> {code}
> if (!deprecationWarnings.isEmpty())
> logger.warn("{} parameters have been deprecated. They have new names and/or value format; For more information, please refer to NEWS.txt", deprecationWarnings);
> {code}
> For example, I saw this log:
> {code}
> WARN 09:07:42,486 [key_cache_save_period, counter_cache_save_period, row_cache_save_period] parameters have been deprecated. They have new names and/or value format; For more information, please refer to NEWS.txt
> {code}
> The "problems" I see are two:
> 1) it pollutes the console for tool commands, when a tool needs to initialise DD, at the very beginning of the output.
> 2) When you look closely, for example at key_cache_save_period, by default, in cassandra.yaml, it has value "4h". My question is: why is it necessary to mark that as deprecated when the value is already in new format? In other words, I would log that warning only in case that the expected value of a property is not in the new format. But when it already is, why do we need to inform a user about that?
> I think it would require to take some extra care for cases like these in YamlConfigurationLoader.getProperty to not add deprecated properties if their value is already new.
>
--
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