From: Fiona Ebner <f.ebner@proxmox.com>
To: "Proxmox VE development discussion" <pve-devel@lists.proxmox.com>,
"Daniel Kral" <d.kral@proxmox.com>,
"Fabian Grünbichler" <f.gruenbichler@proxmox.com>
Subject: Re: [pve-devel] [PATCH ha-manager 09/15] manager: apply colocation rules when selecting service nodes
Date: Mon, 28 Apr 2025 14:46:38 +0200 [thread overview]
Message-ID: <5f66e849-66b7-4ba4-a8d4-e4172a4f5055@proxmox.com> (raw)
In-Reply-To: <99311daa-b736-4591-a134-094579132c1c@proxmox.com>
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
next prev parent reply other threads:[~2025-04-28 12:46 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-25 15:12 [pve-devel] [RFC cluster/ha-manager 00/16] HA colocation rules Daniel Kral
2025-03-25 15:12 ` [pve-devel] [PATCH cluster 1/1] cfs: add 'ha/rules.cfg' to observed files Daniel Kral
2025-03-25 15:12 ` [pve-devel] [PATCH ha-manager 01/15] ignore output of fence config tests in tree Daniel Kral
2025-03-25 17:49 ` [pve-devel] applied: " Thomas Lamprecht
2025-03-25 15:12 ` [pve-devel] [PATCH ha-manager 02/15] tools: add hash set helper subroutines Daniel Kral
2025-03-25 17:53 ` Thomas Lamprecht
2025-04-03 12:16 ` Fabian Grünbichler
2025-04-11 11:24 ` Daniel Kral
2025-03-25 15:12 ` [pve-devel] [PATCH ha-manager 03/15] usage: add get_service_node and pin_service_node methods Daniel Kral
2025-04-24 12:29 ` Fiona Ebner
2025-04-25 7:39 ` Daniel Kral
2025-03-25 15:12 ` [pve-devel] [PATCH ha-manager 04/15] add rules section config base plugin Daniel Kral
2025-04-24 13:03 ` Fiona Ebner
2025-04-25 8:29 ` Daniel Kral
2025-04-25 9:12 ` Fiona Ebner
2025-04-25 13:30 ` Daniel Kral
2025-03-25 15:12 ` [pve-devel] [PATCH ha-manager 05/15] rules: add colocation rule plugin Daniel Kral
2025-04-03 12:16 ` Fabian Grünbichler
2025-04-11 11:04 ` Daniel Kral
2025-04-25 14:06 ` Fiona Ebner
2025-04-29 8:37 ` Daniel Kral
2025-04-29 9:15 ` Fiona Ebner
2025-05-07 8:41 ` Daniel Kral
2025-04-25 14:05 ` Fiona Ebner
2025-04-29 8:44 ` Daniel Kral
2025-03-25 15:12 ` [pve-devel] [PATCH ha-manager 06/15] config, env, hw: add rules read and parse methods Daniel Kral
2025-04-25 14:11 ` Fiona Ebner
2025-03-25 15:12 ` [pve-devel] [PATCH ha-manager 07/15] manager: read and update rules config Daniel Kral
2025-04-25 14:30 ` Fiona Ebner
2025-04-29 8:04 ` Daniel Kral
2025-03-25 15:12 ` [pve-devel] [PATCH ha-manager 08/15] manager: factor out prioritized nodes in select_service_node Daniel Kral
2025-04-28 13:03 ` Fiona Ebner
2025-03-25 15:12 ` [pve-devel] [PATCH ha-manager 09/15] manager: apply colocation rules when selecting service nodes Daniel Kral
2025-04-03 12:17 ` Fabian Grünbichler
2025-04-11 15:56 ` Daniel Kral
2025-04-28 12:46 ` Fiona Ebner [this message]
2025-04-29 9:07 ` Daniel Kral
2025-04-29 9:22 ` Fiona Ebner
2025-04-28 12:26 ` Fiona Ebner
2025-04-28 14:33 ` Fiona Ebner
2025-04-29 9:39 ` Daniel Kral
2025-04-29 9:50 ` Daniel Kral
2025-04-30 11:09 ` Daniel Kral
2025-05-02 9:33 ` Fiona Ebner
2025-05-07 8:31 ` Daniel Kral
2025-03-25 15:12 ` [pve-devel] [PATCH ha-manager 10/15] sim: resources: add option to limit start and migrate tries to node Daniel Kral
2025-04-28 13:20 ` Fiona Ebner
2025-03-25 15:12 ` [pve-devel] [PATCH ha-manager 11/15] test: ha tester: add test cases for strict negative colocation rules Daniel Kral
2025-04-28 13:44 ` Fiona Ebner
2025-03-25 15:12 ` [pve-devel] [PATCH ha-manager 12/15] test: ha tester: add test cases for strict positive " Daniel Kral
2025-04-28 13:51 ` Fiona Ebner
2025-05-09 11:22 ` Daniel Kral
2025-03-25 15:12 ` [pve-devel] [PATCH ha-manager 13/15] test: ha tester: add test cases for loose " Daniel Kral
2025-04-28 14:44 ` Fiona Ebner
2025-05-09 11:20 ` Daniel Kral
2025-03-25 15:12 ` [pve-devel] [PATCH ha-manager 14/15] test: ha tester: add test cases in more complex scenarios Daniel Kral
2025-04-29 8:54 ` Fiona Ebner
2025-04-29 9:01 ` Fiona Ebner
2025-03-25 15:12 ` [pve-devel] [PATCH ha-manager 15/15] test: add test cases for rules config Daniel Kral
2025-03-25 16:47 ` [pve-devel] [RFC cluster/ha-manager 00/16] HA colocation rules Daniel Kral
2025-04-24 10:12 ` Fiona Ebner
2025-04-01 1:50 ` DERUMIER, Alexandre
2025-04-01 9:39 ` Daniel Kral
2025-04-01 11:05 ` DERUMIER, Alexandre via pve-devel
2025-04-03 12:26 ` Fabian Grünbichler
2025-04-24 10:12 ` Fiona Ebner
2025-04-24 10:12 ` Fiona Ebner
2025-04-25 8:36 ` Daniel Kral
2025-04-25 12:25 ` Fiona Ebner
2025-04-25 13:25 ` Daniel Kral
2025-04-25 13:58 ` Fiona Ebner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5f66e849-66b7-4ba4-a8d4-e4172a4f5055@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=d.kral@proxmox.com \
--cc=f.gruenbichler@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal