Always enforce default tier preference (ENFORCE_DEFAULT_TIER_PREFERENCE is ignored) #79751
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
By having MetadataCreateIndexService ignore the ENFORCE_DEFAULT_TIER_PREFERENCE setting (and, by extension, acting as if it's always true).
It's just always true, these tests need to learn to live with that.
The tests that checked what happens when we don't enforce a tier preference don't need to exist anymore. Likewise, since we always enforce we can rename the tests that check what happens when we do.
We'll be removing it one day, and it's only allowed to be true anyway, so there's no point in having it.
Rather, we can strip it from the settings and rely on the default
joegallo
added
>breaking
:Data Management/ILM+SLM
elasticmachine
added
the
Team:Data Management
Collaborator
|
Pinging @elastic/es-data-management (Team:Data Management) |
Contributor
Author
|
Note: this is the alternative PR I mentioned in #79723 (comment) |
by setting the tier preference back to null after the index has been created
henningandersen
approved these changes
Oct 26, 2021
|
|
||
| public void testEnforceDefaultTierPreferenceSetting() { | ||
| Settings settings = Settings.builder() | ||
| .put(DataTier.ENFORCE_DEFAULT_TIER_PREFERENCE_SETTING.getKey(), true) |
Contributor
There was a problem hiding this comment.
I think that this could be randomBoolean() in this version?
Having the setting set at all is what's deprecated, it doesn't matter what the value actually is.
Contributor
Author
|
@elasticmachine run elasticsearch-ci/part-2 |
7 tasks
lockewritesdocs
pushed a commit
to lockewritesdocs/elasticsearch
that referenced
this pull request
Oct 28, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Part of #76147, follow up to #79210 and #79275
#79210 added this new setting, and #79275 made it so the value defaults to
true. This PR goes one further, and makes it so that the setting is deprecated and ignored -- we force a tier preference, and there's no setting to disable that. Mostly it's adjusting the tests to account for that, there were some tests where we were still explicitly setting the value tofalsein order to test 'what if' scenarios.