Add not-preferred allocation decision

[mhl-b]

This PR adds new Enum variant for Decision.Type - NOT_PREFERRED, along with existing NO, THROTTLE, and YES. NOT_PREFERRED is intended for the WriteLoadDecider to indicate not preferable but possible allocations. It's a soft NO. Also changes wire format to enum ordinals.

ES-11998

[elasticsearchmachine]

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

[nicktindall]

This seems pragmatic to me.

Am I right in thinking we chose "soft yes" rather than "soft no" because it was more aligned with existing interpretations of YES/NO? because what we're saying from the WriteLoadConstraintDecider feels more like a soft no than a soft yes to me.

I wonder if the distinction between a soft no and a soft yes will be important one day, or they'll both mean effectively the same thing (i.e. MAYBE).

[mhl-b]

I wonder if the distinction between a soft no and a soft yes will be important one day, or they'll both mean effectively the same thing (i.e. MAYBE).

I'm dont think boolean Preferred will last. My personal opinion is that we need some number value attached to YES, a decision confidence. Especially for non-binary deciders(sounds funny in modern world), like resource based where we have shades of grey rather than clean yes/no. Also not-preferred is a relative term, it serves when only not-preferred options left and we need to choose best one. So this relativity means we need a comparison between decisions, hence some ordering, right?

For example:

• Awareness and MaxRetry are binary deciders and can return NO or YES-100%.
• Resource related deciders can return NO when above some absolute high threshold, and YES-10% when we are reaching limit. Then we can compare Decisions during canAllocate phase and choose best node.

[mhl-b]

Am I right in thinking we chose "soft yes" rather than "soft no" because it was more aligned with existing interpretations of YES/NO? because what we're saying from the WriteLoadConstraintDecider feels more like a soft no than a soft yes to me.

Are you asking about WriteLoadConstraintDecider changes in PR, like this Decision.preferred(NAME, "canRemain() is not enabled"); and return just YES?
If thats the question, then there is no particular reason for using preferred here, just to distinguish between YES and YES_NOT_PREFERRED.

[henningandersen]

I find the preferred dimension unnecessary, let us keep this one-dimensional.

[henningandersen]

I'd prefer a new Type.NOT_PREFERRED, just to keep it simple and not have multi-dimensions here. We can evolve ofc, but starting simple seems ... well simpler. We do not need the other variants of this. And NO not preferred, throttle not preferred etc. does not seem relevant.

This Decision would then also be named NOT_PREFERRED, no need for YES in the name, it is a decision between No and Yes.

[mhl-b]

Changed to a single dimension.

[henningandersen]

LGTM.

[henningandersen]

I think we should add a todo here, preferably with a JIRA number attached. We need to figure out what to do. Perfectly fine to defer.

[nicktindall]

LGTM