Backport PR #16339 to 8.15: settings: add support for observing settings after post-process hooks #16348
+53
−3
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport PR #16339 to 8.15 branch, original message:
Because logging configuration occurs after loading the
logstash.yml
settings, deprecation logs fromLogStash::Settings::DeprecatedAlias#set
are effectively emitted to a null logger and lost.By re-emitting these deprecations after the post-process hooks, we can ensure that they make their way to the deprecation log. This change adds support for any setting that responds to
Object#observe_post_process
to receive it after all post-processing hooks have been executed.Release notes
Fixes an issue where the deprecation log does not contain entries related to providing deprecated settings by ensuring that they are re-emitted after the logger has been configured.
What does this PR do?
Fixes an issue where the deprecation log does not contain entries related to providing deprecated settings by ensuring that they are re-emitted after the logger has been configured.
Why is it important/What is the impact to the user?
Settings like
http.enabled
have been deprecated and superseded with other configuration since 7.x, but the deprecation log entries have been sent to the logger before it was configured, causing them to be lost. By re-emitting the deprecation warnings after the logger is configured we ensure that users have a chance to fix the issue and migrate to the new setting prior to the eventual removal of the deprecated ssettings.Checklist
[ ] I have made corresponding changes to the documentation[ ] I have made corresponding change to the default configuration files (and/or docker env variables)Author's Checklist
How to test this PR locally
Related issues
Resolves: #16332