[
https://issues.apache.org/jira/browse/SOLR-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14945144#comment-14945144
]
Ludovic Boutros commented on SOLR-8117:
---------------------------------------
hmm, I see, the rules should be considered as a mandatory state before and
after the collection creation.
This type of condition (<1) should be considered as invalid. I misunderstood
the rule configuration.
Thank you Paul.
I will try to reproduce the other behavior:
sometimes a collection creation is allowed and sometimes not with the same
cluster and the same rules.
I use these two rules:
rule=shard:*,host:*,replica:<2
rule=shard:*,cores:<2
The last time, I had to retry 3 times to finally create a collection (7 shards,
2 replicas per shard).
The demo cluster contains 4 hosts, 16 nodes (4 per host), 14 empty nodes.
With your explaination, it should never be allowed to create this collection
because all nodes contain 2 cores after the collection creation.
Or perhaps, the two rules are not applied the way I think.
By the way, the behavior should always be the same.
> Rule-based placement issue with 'cores' tag
> --------------------------------------------
>
> Key: SOLR-8117
> URL: https://issues.apache.org/jira/browse/SOLR-8117
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 5.3, 5.3.1
> Reporter: Ludovic Boutros
> Assignee: Noble Paul
> Attachments: SOLR-8117.patch
>
>
> The rule-based placement fails on an empty node (core count = 0) with
> condition 'cores:<1'.
> It also fails if current core number is equal to the core number in the
> condition - 1.
> During the placement strategy process, the core counts for a node are
> incremented when all the rules match.
> At the end of the code, an additional verification of all the conditions is
> done with incremented core count and therefore it fails.
> I don't know why this additional verification is needed and removing it seems
> to fix the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
