-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Miscellaneous ILM cleanups #118488
Miscellaneous ILM cleanups #118488
Conversation
The ordering of the phases and the removal and readdition of the hot phase are actually redundant, since the hot phase is the first ordered phase anyway.
Pinging @elastic/es-data-management (Team:Data Management) |
Function<String, LifecycleAction> randomAction = getNameToActionFunction(); | ||
// as what actions end up in the hot phase influence what actions are allowed in the subsequent phases we'll move the hot phase | ||
// at the front of the phases to process (if it exists) | ||
if (phaseNames.contains(TimeseriesLifecycleType.HOT_PHASE)) { |
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.
Do we not need to worry about HOT_PHASE coming first any more? I don't really understand why it was necessary in the first place.
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.
My read of it is that this code was maybe necessary once, but the loop after this that I didn't remove ended up making this code redundant anyway. https://github.com/elastic/elasticsearch/pull/118488/files/93a7c08283627686d9ef83f7e80793be004c8bb8#diff-ea4f8cb2981d1e363c5308fc815b3ce4f94ec116f7e9691d69bbe63d96c607a4R155-R161
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.
@@ -269,9 +269,8 @@ public Set<Step.StepKey> parseStepKeysFromPhase(String policy, String currentPha | |||
return parseStepsFromPhase(policy, currentPhase, phaseDefNonNull).stream().map(Step::getKey).collect(Collectors.toSet()); | |||
} catch (IOException e) { | |||
logger.trace( | |||
() -> String.format( | |||
Locale.ROOT, | |||
"unable to parse steps for policy [{}], phase [{}], and phase definition [{}]", |
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.
Oh nice -- we pick up a bug fix!
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.
Yeah, I'm just annoyed I didn't catch this on the first go around!
@@ -1436,6 +1436,6 @@ private void assertClusterStateStepInfo( | |||
assertEquals(expectedstepInfoValue, newLifecycleState.stepInfo()); | |||
assertEquals(oldLifecycleState.phaseTime(), newLifecycleState.phaseTime()); | |||
assertEquals(oldLifecycleState.actionTime(), newLifecycleState.actionTime()); | |||
assertEquals(newLifecycleState.stepTime(), newLifecycleState.stepTime()); |
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.
Nice, another (test) bug fix.
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, although I don't understand the one block of test code you removed (or why it was there in the first place).
💚 Backport successful
|
This is an unconnected bunch of commits that are just tidying some little things here and there that I ran into in the ILM code while I was working on my current task.
This is a continuation of #118466 and #118338, there's also a little bit of #118354 in there, too.