Skip to content

Conversation

@idegtiarenko
Copy link
Contributor

No description provided.

@idegtiarenko idegtiarenko added :Distributed Coordination/Allocation All issues relating to the decision making around placing a shard (both master logic & on the nodes) Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. labels Oct 3, 2022
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-distributed (Team:Distributed)

if (info != null
&& info.getLastAllocatedNodeId() != null
&& routingNodes.node(info.getLastAllocatedNodeId()) != null
&& ignoredShards.contains(shardRouting) == false) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should we do it even if shard is ignored?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am writing a unit test for this

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we only want to do this if a shard is ignored because that indicates the GatewayAllocator is still taking responsibility for it (and therefore we expect will eventually assign it). If the shard is not ignored then its last-allocated ID shouldn't be relevant, it's effectively a new shard and should be left for the delegate allocator.

DaveCTurner
DaveCTurner previously approved these changes Oct 3, 2022
Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

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

LGTM with one comment nit.

if (info != null
&& info.getLastAllocatedNodeId() != null
&& routingNodes.node(info.getLastAllocatedNodeId()) != null
&& ignoredShards.contains(shardRouting) == false) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we only want to do this if a shard is ignored because that indicates the GatewayAllocator is still taking responsibility for it (and therefore we expect will eventually assign it). If the shard is not ignored then its last-allocated ID shouldn't be relevant, it's effectively a new shard and should be left for the delegate allocator.

@DaveCTurner DaveCTurner dismissed their stale review October 3, 2022 13:32

this approach doesn't work

@DaveCTurner
Copy link
Contributor

We discussed in another channel - this approach doesn't quite work because it might try and assign a replica before its primary. Instead we should incorporate the previous node ID into the targetNodes used when we're aligning things with the previous desired balance.

Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

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

LGTM again

@idegtiarenko idegtiarenko merged commit bd2bbf0 into elastic:feature/desired-balance-allocator Oct 4, 2022
@idegtiarenko idegtiarenko deleted the fix_testSingleIndexStartedShard branch October 4, 2022 06:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Distributed Coordination/Allocation All issues relating to the decision making around placing a shard (both master logic & on the nodes) Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants