[pve-devel] [PATCH cluster v2 3/3] datacenter config: introduce feature flag for location rules

[Daniel Kral]

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.