From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pve-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 86E4D1FF16F for <inbox@lore.proxmox.com>; Tue, 29 Apr 2025 11:22:37 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 10CF97CF3; Tue, 29 Apr 2025 11:22:47 +0200 (CEST) Message-ID: <6f50fe21-7b15-4766-a21d-56e7b4168d7a@proxmox.com> Date: Tue, 29 Apr 2025 11:22:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Daniel Kral <d.kral@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com>, =?UTF-8?Q?Fabian_Gr=C3=BCnbichler?= <f.gruenbichler@proxmox.com> References: <20250325151254.193177-1-d.kral@proxmox.com> <20250325151254.193177-11-d.kral@proxmox.com> <1743681290.ng3l34qeu2.astroid@yuna.none> <99311daa-b736-4591-a134-094579132c1c@proxmox.com> <5f66e849-66b7-4ba4-a8d4-e4172a4f5055@proxmox.com> <ce9a801d-c28b-4480-a402-488448836a1f@proxmox.com> Content-Language: en-US From: Fiona Ebner <f.ebner@proxmox.com> In-Reply-To: <ce9a801d-c28b-4480-a402-488448836a1f@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.036 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH ha-manager 09/15] manager: apply colocation rules when selecting service nodes X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com> Am 29.04.25 um 11:07 schrieb Daniel Kral: > On 4/28/25 14:46, Fiona Ebner wrote: >> 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. > > What scenario would that be? Or do you mean just disallowing migrating > services contradicting the HA (colocation) rules? I just meant we need to be careful when implementing if we want to apply new rules directly/honor them while services are running. E.g. say a new rule vm:101<->vm:102 is introduced, with 101 on node A and 102 on node B. Then the HA manager should only issue a migration command 101 to B or 102 to A, but not both 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. > > Yes, it would improve UX to add migration blockers for these in the > future as the info could be exposed there without putting too much > dependency between pve-manager and pve-ha-manager. > > I'll try to add the blockers for colocation rules for v1 or a follow-up. Might be better as a follow-up/separate series, to not blow up the series here too much. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel