New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate settings in .yml and .json #24059
Conversation
One thing I am unsure about is how to handle packaging correctly with the change in name. I'm thinking we actually need to have something in the packaging scripts, otherwise I think the user will end up with both |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks great. You covered all the things I thought of. I left a few comments.
@@ -44,6 +47,9 @@ | |||
|
|||
public class InternalSettingsPreparer { | |||
|
|||
private static Logger logger = ESLoggerFactory.getLogger("settings"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why name this logger against our convention? It's not even prefixed with "org.elasticsearch" but I think you should only pass InternalSettingsPreparer.class
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was trying to make the context in the log message clearer (that it had to do with settings) vs a user thinking "what is InternalSettingsPreparer". But I changed it as you suggested. If we don't want to allow using getLogger(String)
, we should remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a few legitimate uses for this method, namely the loggers that we provide to Netty, and the naming for the circuit breaker loggers, as well as setting logging levels via the API (all we get there from the user input is the name of the logger, so we have to have a way to look up loggers by name).
@@ -112,6 +118,9 @@ public static Environment prepareEnvironment(Settings input, Terminal terminal, | |||
throw new SettingsException("multiple settings files found with suffixes: " | |||
+ Strings.collectionToDelimitedString(foundSuffixes, ",")); | |||
} | |||
if (foundSuffixes.contains(".yml") || foundSuffixes.contains(".json")) { | |||
deprecationLogger.deprecated("elasticsearch.yaml and elasticsearch.json are deprecated. Rename your configuration file to elasticsearch.yaml."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Three-letter "yml" for the first instance of "yaml" here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can give a more specific message too: yml -> yaml only if yml, json -> yaml only if json instead of a general message covering both cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, I wrote this before doing find replace. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because we disallow multiple settings files (a few lines up), we are certain here that foundSuffixes
contains at most one element. So we can write:
if (foundSuffixes.contains(".yml") || foundSuffixes.contains(".json")) {
final DeprecationLogger deprecationLogger = new DeprecationLogger(Loggers.getLogger(InternalSettingsPreparer.class));
deprecationLogger.deprecated(
"elasticsearch[{}] is deprecated; rename your configuration file to elasticsearch.yaml",
foundSuffixes.iterator().next());
}
I think this is clean, and let's us scope the logger locally so we can avoid the static fields.
@@ -44,6 +47,9 @@ | |||
|
|||
public class InternalSettingsPreparer { | |||
|
|||
private static Logger logger = ESLoggerFactory.getLogger("settings"); | |||
private static DeprecationLogger deprecationLogger = new DeprecationLogger(logger); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also I wonder if these loggers should be initialized in the one place they are used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is, locally, and not even be a field here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since I split the message into two branches, I left these static.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my suggestion for how I think that we can avoid this.
@jasontedor Maybe we should separate adding the deprecation from changing the shipped file? Then we could only do the default file change in 6.0. Users would then get the deprecation warning in 5.5, and know that they need to rename their file before upgrading to 6.0. |
This commit adds a deprecation warning when elasticsearch.yml or elasticsearch.json is read during startup. relates elastic#19391
@jasontedor I pushed 129bc76 which simplies this commit to be just deprecation. I will cutover the docs and shipped config file in a followup to master only (with removal of support for anything but .yaml and helpful error message on the old names existing). |
@elasticmachine retest this please @jasontedor ping |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a comment.
@@ -107,6 +109,11 @@ public static Environment prepareEnvironment(Settings input, Terminal terminal, | |||
throw new SettingsException("multiple settings files found with suffixes: " | |||
+ Strings.collectionToDelimitedString(foundSuffixes, ",")); | |||
} | |||
if (foundSuffixes.contains(".yml") || foundSuffixes.contains(".json")) { | |||
final DeprecationLogger deprecationLogger = new DeprecationLogger(Loggers.getLogger(InternalSettingsPreparer.class)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sadly, the logging here happens before we've fully configured logging. This means that it will appear in the console log with a default format, and before we've configured deprecation logging so it won't end up in the deprecation log on disk.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. I pushed 7f796b0 to address this.
retest this please |
@elasticmachine retest this please |
jenkins test this please |
@jasontedor I finally got a clean CI run, can you look again? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
This commit adds a deprecation warning when elasticsearch.yml or elasticsearch.json is read during startup. relates #19391
This commit adds a deprecation warning when elasticsearch.yml or
elasticsearch.json is read during startup. It also fixes all docs
references, tests, and renames the default file that comes in our packages.
relates #19391