Hide Forgot
Description of problem: pcs allows you to place scores on avoids/prefers location constraints. Internally these are transferred to negative numbers for "avoids" and positive numbers for "prefers" constraints. The problem here is that you can supply the "opposite" sign to the value and it will get the opposite meaning. Example: pcs constraint location dummy avoids node=-10 will effectively prefer the node with score 10. Pcs constraint should enforce positive numbers on "prefers" constraint and negative for "avoids". avoids node=10 == score -10 avoids node=-10 == score -10 prefers node=10 == score 10 prefers node=-10 == error? Pacemaker docs already cover -score as avoidance score in general, so I'd not consider it being an error if the score is negative. pcs location <resource id> avoids ... should also specify the default value as -INFINITY for consistency. Version-Release number of selected component (if applicable): pcs-0.9.152-7.el7.x86_64 How reproducible: always Steps to Reproduce: 1. pcs resoruce create dummy dummy 2. pcs constraint location dummy avoids virt-154=-20 3. pcs constraint Location Constraints: Resource: dummy Enabled on: virt-154 (score:20) Actual results: possibility to have positive score on negative (avoids) constraint Expected results: avoids always negative score, prefers always positive score Additional info:
The basic form of the command is "pcs constraint location <resource> prefers|avoids <node>" which creates a constraint with INFINITE or -INFINITE score respectively. In an extended form of the command it is possible to specify a score, which means how much the node should be preferred or avoided by the resource. Consider this: resource prefers node1=100 resource prefers node2=50 resource prefers node3=0 resource prefers node4=-75 In this scenario the resource prefers node1, node2, node3 and node4 in that order. Eliminating the minus sign would change the order to node1, node4, node2, node3. This is very counter-intuitive as -75 is not greater than 50. The same goes for "avoids": resource avoids node1=100 resource avoids node2=50 resource avoids node3=0 resource avoids node4=-75 Certainly node2 should be avoided less than node1. And by the same logic node4 should be avoided less than node2. Avoiding node4 more than node2 as requested is counter-intuitive. The current behavior is correct. Moreover the requested behavior breaks backward compatibility.