Am 29.04.25 um 10:37 schrieb Daniel Kral: > On 4/25/25 16:06, Fiona Ebner wrote: >> Am 11.04.25 um 13:04 schrieb Daniel Kral: >>> On 4/3/25 14:16, Fabian Grünbichler wrote: >>>> On March 25, 2025 4:12 pm, Daniel Kral wrote: >>> Also, I was curious about how that would work out for the case where a >>> negative colocation rule was defined for three nodes with those rules >>> split into three rules (essentially a cycle dependence). This should in >>> theory have the same semantics as the above rule set: >>> >>> colocation: stick-together1 >>> services vm:101,vm:104 >>> affinity together >>> strict 1 >>> >>> colocation: stick-together2 >>> services vm:104,vm:102 >>> affinity together >>> strict 1 >>> >>> colocation: very-lonely-services1 >>> services vm:101,vm:102 >>> affinity separate >>> strict 1 >>> >>> colocation: very-lonely-services2 >>> services vm:102,vm:103 >>> affinity separate >>> strict 1 >>> >>> colocation: very-lonely-services3 >>> services vm:101,vm:103 >>> affinity separate >>> strict 1 >>> >>> Without the merge of positive rules, 'check_inner_consistency' would >>> again not detect the inconsistency here. But with the merge correctly >>> applied before checking the consistency, this would be resolved and the >>> effective rule set would be: >> >> I suppose the effective rule set would still also contain the two >> 'together' rules, or? > > No, here it would not. I found it would be most fair or reasonable that > if a positive and a negative colocation rule contradict each other to > drop both of them. Here the conflicts are > > stick-together1 -- very-lonely-services1 > stick-together2 -- very-lonely-services1 > > so all three of them will be dropped from the rule set. > > Seeing this again here, such cases definitely benefit from the immediate > response with the 'conflict'/'ineffective' state to show users that > those won't be applied instead of only logging it.
I don't think dropping all conflicting rules is best. Say you have a rule between 100 services and that conflicts with a rule with just 2 services. Dropping the latter only is much preferred then IMHO. In general, I'd argue that the more rules we can still honor, the better from a user perspective. I don't think it's worth going out of our way though and introduce much complexity to minimize it, because conflicts are usually prevented while configuring already. >>> colocation: very-lonely-services2 >>> services vm:102,vm:103 >>> affinity separate >>> strict 1 >>> >>> colocation: very-lonely-services3 >>> services vm:101,vm:103 >>> affinity separate >>> strict 1 >>> >>> It could be argued, that the negative colocation rules should be merged >>> in a similar manner here, as there's now a "effective" difference in the >>> semantics of the above rule sets, as the negative colocation rule >>> between vm 101 and vm 103 and vm 102 and vm 103 remains. >>> >>> What do you think? >> >> I don't think there's a particular need to also merge negative rules >> between services (when they form a complete graph). It won't make a >> difference if there are no conflicts with positive rules and in edge >> cases when there are conflicts (which usually gets caught while editing >> the rules), it's better to drop fewer rules, so not merging is an >> advantage. Or do you have a particular advantage in favor of merging in >> mind? > > Yes, I think so too. > > There's quite the semantic difference between positive and negative > colocation rules here. "Connected" positive colocation relationships > (strict ones in particular) must be co-located in the end anyway, so it > makes sense to merge them. Negative colocation relationships must be > defined in a "circular" way and might just happen by coincidence for > small scenarios. > > But one thing that just struck me is that what if the user intentionally > wrote them as separate rules? Then it might be confusing that all rules > are dropped and not just the minimal amount that contradict other > rules... Then check_inner_consistency() would just drop the minimal > amount of rules that need to be dropped as in the above example. > > It would be a softer interpretation of the rules indeed, but it might > benefit the user in the end and make things easier to follow from the > user perspective. If there's no opposition to that, I'd tend to drop the > merging for any rules after all. Having conflicts is already a bit of an edge case, so I don't think we need to go out of our way to avoid merging of positive rules. But if it doesn't increase the complexity much, it's fine either way IMHO. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
