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
