Completely agree that this information can be highly useful, any objection is on grounds of practicality - which is why we've generally directed people to tweak values and see how the final scores change with crm_simulate -sx and/or the horrifically verbose debug output.

Consider one place that scores are modified:

    for (gIter = rsc->rsc_cons_lhs; gIter != NULL; gIter = gIter->next) {
        rsc_colocation_t *constraint = (rsc_colocation_t *) gIter->data;

        rsc->allowed_nodes =
            constraint->rsc_lh->cmds->merge_weights(
                constraint->rsc_lh, rsc->id, rsc->allowed_nodes,
                constraint->node_attribute,
                (float)constraint->score / INFINITY,
                pe_weights_rollback);
    }

Since rsc->allowed_nodes is a hashtable of node_t, we'd need to add an ordered list of { score_delta, description } to the node_t struct for tracking changes.

I could imagine maintaining that extra list could get rather costly in exactly the kind of large complex installations that it would be useful in.
Keep in mind too, that since this logic is in a library shared between the cli and cluster, the main pengine process would also incur the overhead. 

Another potential wrinkle, the score we bring across from constraint->rsc_lh will have also been calculated from a number of different constraints, should one include a rolled up value { -40, "anti-colocation with X" } or each of the changes that summed up into the -40?  I can imagine each would be useful in different situations.

Another source of problems is that if location constraints are in use, the scores will change based on where things are running.
If A is colocated with B, then the user might see { -4000, "anti-colocation with X on Y" } if B is running on its most preferred node, but { -40, "anti-colocation with X on Z" } on another node.

Andrew's first mentioned complication (the cost of tracking this) could potentially be addressed by having a flag somewhere to "track score details", only set if a new option is passed to crm_simulate.

However the other complications are inherent. At some level, Pacemaker's policy engine is a rudimentary AI, and teasing out how it gets from point A to point B is impractical. I'm not sure a user-friendly crm_simulate output for this is a reasonable goal. Perhaps instead we could add more detail to log messages at the debug or trace level, but that's difficult for end users to follow.

Definitely not 7.4 timeframe

(In reply to Ken Gaillot from comment #2)
> Andrew's first mentioned complication (the cost of tracking this) could
> potentially be addressed by having a flag somewhere to "track score
> details", only set if a new option is passed to crm_simulate.

agreed though i'm still a bit worried about all the functions that would need to change their parameter lists to support this ('this' being the overall feature and access to the flag specifically). not impossible, just invasive.

> 
> However the other complications are inherent. At some level, Pacemaker's
> policy engine is a rudimentary AI, and teasing out how it gets from point A
> to point B is impractical. I'm not sure a user-friendly crm_simulate output
> for this is a reasonable goal. Perhaps instead we could add more detail to
> log messages at the debug or trace level, but that's difficult for end users
> to follow.

potentially we could add a tag to the relevant log messages so that they alone can be selectively enabled.  the challenge there is that the PE does a lot of walking up and down the resource stack and the admin is likely to see a bunch of calculations that eventually get thrown out.

> 
> Definitely not 7.4 timeframe

definitely :)

Not 7.5 either, likely to end up WONTFIX unless we get more development capacity

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

An equivalent report has been filed upstream.