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 67E511FF164 for <inbox@lore.proxmox.com>; Fri, 20 Jun 2025 17:43:17 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 36C0FFD5A; Fri, 20 Jun 2025 17:43:46 +0200 (CEST) Message-ID: <8451d94e-176a-49e6-95ac-f25e7b4cfe9c@proxmox.com> Date: Fri, 20 Jun 2025 17:43:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Daniel Kral <d.kral@proxmox.com> To: pve-devel@lists.proxmox.com References: <20250620143148.218469-1-d.kral@proxmox.com> Content-Language: en-US In-Reply-To: <20250620143148.218469-1-d.kral@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.011 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] [RFC common/cluster/ha-manager/docs/manager v2 00/40] HA colocation rules 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com> On 6/20/25 16:31, Daniel Kral wrote: > Changelog > --------- Just noticed that I missed one detail that might be beneficial to know, so following the patch changes is easier: - migrate ha groups internally in the HA Manager to ha location rules, so that internally these can already be replaced; the test cases in ha-manager patch #09 (stuck in moderator review because it became quite large) are there to ensure that the migration produces the same result for the migrated location rules On 6/20/25 16:31, Daniel Kral wrote: > TODO > ---- > > There are some things left to be done or discussed for a proper patch > series: Also other small things to point out: - Add missing comment field in rule edit dialog - Since ha location rules were designed so that these will never be dropped by the rule checks (this is because there was no notion of dropping ha groups), location rules are the only rules that can introduce conflicts, e.g. introducing another priority group in the location rule or restricting colocated services too much. What should we do here? allow dropping location rules when these are not automatically migrated from groups? Or show a conformation dialog when creating these, so that users are warned? Both of them would introduce some more complexity/state in how rules are checked. For now, these conflicts are created silently. - Reload both ha location and ha colocation rules if one of them gets changed (e.g. when a location rule is added that creates a conflict in ha colocation rules, then it will only show the conflict on the next reload). > > - Implement check which does not allow negative colocation rules with > more services than nodes, because these cannot be applied. Or should > we just fail the remaining services which cannot be separated to any > node since these do not have anywhere to go? > > - How can the migration process from HA groups to HA location rules be > improved? Add a 'Migrate' button to the HA Groups page and then > auto-toggle the use-location-rules feature flag? Should the > use-location-rules feature flag even be user-toggleable? Another point here for the migration of HA groups to HA location rules is how we would name these new location rules? In the auto-migration the code currently prefixes the group name with `_group_` so that they cannot conflict with config keys as these cannot start with a underscore. If we introduce a manual "Migrate" button, then we'd need to handle name collisions with either already existing HA location rules (especially if we allow switching back and forward) and existing HA colocation rules. > > - Add web interface and/or CLI facing messages about the HA service > migration blockers and side-effects. The rough idea would be like the > following (feedback highly appreciated!): > > - For the web interface, I'd make these visible through the already > existing precondition checks (which need to also be added for > containers, as there is no existing API endpoint there). > Side-effects would be 'warning' items, which just state that some > positively colocated service is migrated with them (the 'Migrate' > button then is the confirmation for that). Blockers would be > 'error' items, which state that a negatively colocated service is > on the requested target node and therefore the migration is > blocked because of that. > > - For bulk migrations in the web interface, these are still visible > through the console that is popped up afterwards, which should > print the messages from the migrate/relocate crm-command API > endpoints. > > - For the CLI, I'd add another 'force' flag or something similar. If > there are side-effects and the force flag is not set, then no > migration happens at all, but the user gets a list of the > migrations that will be done and should confirm by making another > call to 'migrate'/'relocate' with the force flag set to confirm > these choices. > > - Add more user documentation (especially about conflicts, migrations, > restrictions and failover scenario handling) > > - Add mixed test cases with HA location and HA colocation rules _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel