> Let me explain why I decided to do it this way. I thought that if it > doesn't matter where the instance will be placed either on machine a > or on a machine b, it's possible to select both locations as > desired. In that case if one location desire is satisfied - it's ok > and there is no reason for making cluster score bigger.
Then this would be a change of the specification, so at least the design document would have to be updated; and your patch description quoting "instances tagged htools:desiredlocation:x where their primary node is not tagged with x." as well... I'm happy with that semanic change, but then please update the documentation as well. Also, I forgot in the previous review, that the hbal man pages needs to be updated as well in the same patch series. > On the other hand, if we have such contradictive desired locations, > one of them will be always unsatisfied. Since we care only about > metric changes but not about its absolute value it's ok to add plus > one for each unsatisfied desired location as you suggest. The point is that location/failure domains need not be disjoint; they might be hierarchical (e.g., data center, room, rack) but also contain completely orthogonal information (e.g., manufacturer, machine model). So why disallow requests like "I want this instance to be placed in this data center with on one of our super-fast model-X machines"? Regards, Klaus -- Klaus Aehlig Google Germany GmbH, Dienerstr. 12, 80331 Muenchen Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschaeftsfuehrer: Graham Law, Christine Elizabeth Flores
