Am 11.04.25 um 17:56 schrieb Daniel Kral:
> On 4/3/25 14:17, Fabian Grünbichler wrote:
>> On March 25, 2025 4:12 pm, Daniel Kral wrote:
>>> +sub apply_positive_colocation_rules {
>>> + my ($together, $allowed_nodes) = @_;
>>> +
>>> + return if scalar(keys %$together) < 1;
>>> +
>>> + my $mandatory_nodes = {};
>>> + my $possible_nodes = PVE::HA::Tools::intersect($allowed_nodes,
>>> $together);
>>> +
>>> + for my $node (sort keys %$together) {
>>> + $mandatory_nodes->{$node} = 1 if $together->{$node}->{strict};
>>> + }
>>> +
>>> + if (scalar keys %$mandatory_nodes) {
>>> + # limit to only the nodes the service must be on.
>>> + for my $node (keys %$allowed_nodes) {
>>> + next if exists($mandatory_nodes->{$node});
>>> +
>>> + delete $allowed_nodes->{$node};
>>> + }
>>> + } elsif (scalar keys %$possible_nodes) {
>>
>> I am not sure I follow this logic here.. if there are any strict
>> requirements, we only honor those.. if there are no strict requirements,
>> we only honor the non-strict ones?
>
> Please correct me if I'm wrong, but at least for my understanding this
> seems right, because the nodes in $together are the nodes, which other
> co-located services are already running on.
>
> If there is a co-located service already running somewhere and the
> services MUST be kept together, then there will be an entry like 'node3'
> => { strict => 1 } in $together. AFAICS we can then ignore any non-
> strict nodes here, because we already know where the service MUST run.
>
> If there is a co-located service already running somewhere and the
> services SHOULD be kept together, then there will be one or more
> entries, e.g. $together = { 'node1' => { strict => 0 }, 'node2' =>
> { strict => 0 } };
>
> If there is no co-located service already running somewhere, then
> $together = {}; and this subroutine won't do anything to $allowed_nodes.
>
> In theory, we could assume that %$mandatory_nodes has always only one
> node, because it is mandatory. But currently, we do not hinder users
> manually migrating against colocation rules (maybe we should?) or what
> if rules suddenly change from non-strict to strict. We do not auto-
> migrate if rules change (maybe we should?).
I feel like we should trigger auto-migration for strict colocation
rules. I.e. apply the rules earlier in select_service_node(), before the
"keep current node" early return.
With nofailback=0, we do not keep the current node when node priorities
change for HA groups or the service's group changes, so it feels
consistent to do the same for colocation rules. We'll need to be careful
not to get a "both services now migrate towards each other" switch-up
scenario of course.
We also don't hinder migrating against group priorities, where, with
nofailback=0, it will migrate straight back again. This can be improved
of course, but nothing new, so I'd consider it orthogonal to the
colocation implementation here.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
