Skip to content

Conversation

@talevy
Copy link
Contributor

@talevy talevy commented Jul 31, 2018

Since replica counts and allocation rules are set separately, it is not always clear how many replicas are to be allocated in the allocate action. Moving the replicas action to occur at the same time as the allocate action, resolves this confusion that could end an undesired state. This means that the ReplicasAction is removed, and a new optional replicas parameter is added to AllocateAction.

@talevy talevy added WIP :Data Management/ILM+SLM Index and Snapshot lifecycle management labels Jul 31, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

@talevy talevy force-pushed the ilm-replica-allocate branch 4 times, most recently from 224243c to 1eeac50 Compare August 6, 2018 16:44
@talevy talevy force-pushed the ilm-replica-allocate branch from 1eeac50 to fea1f5e Compare August 6, 2018 18:17
@talevy talevy removed the WIP label Aug 6, 2018
@talevy talevy requested review from colings86 and dakrone August 6, 2018 21:26
Copy link
Contributor

@colings86 colings86 left a 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 asking for an extra test but otherwise I think this is good

assertThat(getStepKey(settings), equalTo(TerminalPolicyStep.KEY));
assertThat(settings.get(IndexMetaData.INDEX_NUMBER_OF_REPLICAS_SETTING.getKey()), equalTo(String.valueOf(finalNumReplicas)));
});
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we also add a test that tests the bug I found (so where we change both replicas and allocate at the same times on a configuration where the resulting nodes would not be enough to allocate the original number of replicas)?

@talevy
Copy link
Contributor Author

talevy commented Aug 7, 2018

@colings86 thanks for taking a look. I've added a unit test to check the allocation of an unallocated replica

Copy link
Contributor

@colings86 colings86 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

AllocateAction other = (AllocateAction) obj;
return Objects.equals(include, other.include) && Objects.equals(exclude, other.exclude) && Objects.equals(require, other.require);
return Objects.equals(numberOfReplicas, other.numberOfReplicas) && Objects.equals(include, other.include)
&& Objects.equals(exclude, other.exclude) && Objects.equals(require, other.require);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: can we put each of these on its own line as it makes debugging much easier?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup

@talevy
Copy link
Contributor Author

talevy commented Aug 8, 2018

thanks!

@talevy talevy merged commit 2fc3f1d into elastic:index-lifecycle Aug 8, 2018
@talevy talevy deleted the ilm-replica-allocate branch August 8, 2018 18:43
jasontedor pushed a commit that referenced this pull request Aug 17, 2018
Since replica counts and allocation rules are set separately, it is not always clear how many replicas are to be allocated in the allocate action. Moving the replicas action to occur at the same time as the allocate action, resolves this confusion that could end an undesired state. This means that the ReplicasAction is removed, and a new optional replicas parameter is added to AllocateAction.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Data Management/ILM+SLM Index and Snapshot lifecycle management >enhancement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants