From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id CCD861FF16F for ; Tue, 24 Jun 2025 09:28:55 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E159A1FECA; Tue, 24 Jun 2025 09:29:29 +0200 (CEST) Message-ID: Date: Tue, 24 Jun 2025 09:29:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Thomas Lamprecht , Proxmox VE development discussion References: <20250620143148.218469-1-d.kral@proxmox.com> <20250620143148.218469-5-d.kral@proxmox.com> <8694ef39-f186-4219-93e9-0f25ea539011@proxmox.com> Content-Language: en-US From: Daniel Kral In-Reply-To: <8694ef39-f186-4219-93e9-0f25ea539011@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.012 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 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 cluster v2 3/3] datacenter config: introduce feature flag for location rules X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On 6/23/25 17:58, Thomas Lamprecht wrote: > Am 20.06.25 um 16:31 schrieb Daniel Kral: >> diff --git a/src/PVE/DataCenterConfig.pm b/src/PVE/DataCenterConfig.pm >> index 3c983b8..76c5706 100644 >> --- a/src/PVE/DataCenterConfig.pm >> +++ b/src/PVE/DataCenterConfig.pm >> @@ -130,6 +130,12 @@ register_standard_option( >> >> my $ha_format = { >> shutdown_policy => get_standard_option('pve-ha-shutdown-policy'), >> + 'use-location-rules' => { >> + type => 'boolean', >> + description => "Whether HA Location rules should be used instead of HA groups.", >> + optional => 1, >> + default => 0, > > it's IMO rather odd that one can enable this, then do some CRUD stuff and > then disable this flag here again, feels rather awkward and prone to user > errors. > > I'd much rather see a transparent switch, where the new affinity system > parses and handles existing group definition, and when anything is written > out (group or affinity changes) then writes those group definitions also > out as such affinity rules and drops the group definitions (or just ignore > them completely once an affinity rule config exists). > > If the building blocks are there this should not be really _that_ hard > I think. I'm not a fan of it myself right now how it works and it would also prefer a "one-time" switch and users not being able to go back and forth as it introduces many unnecessary states that we need to also test (i.e. going back from location rules to groups). The migration part from groups to the service config + location rules are already there as HA groups are converted to HA location rules and then applied as such after patch ha-manager #11 and #12. I like the idea of writing out new/existing groups to location rules, but the only part that would still be missing here for me is how we should inform users about this? It would feel rather irritating if they're testing out the colocation rules and suddenly their groups are gone and converted to location rules. @Fiona suggested a "Convert to Location Rules" button in the web interface and else a API/CLI endpoint once off-list, maybe that could do the trick? As soon as the conversion was successful (no naming conflicts, group reference was removed from services, etc.), the groups config is dropped and that is the indicator whether location rules should be used or not. For new users that would also be true as the group config doesn't exist yet. What do you think? I'd also prevent users then to create HA groups if the group config doesn't already exist, so that new users already start to use the location rules instead. Resolving naming conflicts could just be a mapping table in the web interface where users can choose the "new" location rules names, but I'm wondering if there's a better way to do this, especially when users do that migration on the CLI. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel