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

[Daniel Kral]

On 6/24/25 09:51, Thomas Lamprecht wrote:
> Am 24.06.25 um 09:29 schrieb Daniel Kral:
>> 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.
> 
> If you think that's irritating it always will be, so then we should
> keep the groups as is (how they are internal handled and represented
> doesn't matter).
> 
> But if we really want to replace groups by this then why should this
> even be irritating? Upgrade and the groups are gone and there are
> just affinity/anti-affinity rules view/api left, the user handles
> it purely over that groups are no more and the parse+write is the
> transparent upgrade. That way the admin doesn't need to do anything,
> which is always a huge win, and there is only one API/UI to manage
> those so it's rather crystal clear what happens; IMO much less confusing
> than any enable/disable or active conversion, as once we can convert
> automatically anyway, why add extra work and make the user do it?
> 
> Sure, the implementation needs to work, but that it does anyway
> (or what else should a user do when they enabled this or pressed
> convert?¿), that's what unit tests and QA/testing is for.
> 
> Especially with the upcoming major release we would have a chance
> to make an easy and clean transition here. But we can still do this
> later on, then we need to keep the API for groups and wire it to
> location rules, not as nice, but I do not think the group API is
> heavily used in automation, or at least anybody will happily switch
> over to affinity rule API as any automation probably tried to
> workaround the lack of those flexible rules, so for the user it's
> still better than what's proposed here IMO.
> 
>> @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?
> 
> No, please no convert buttons, that's just as "irritating", especially
> without a convert back button, and on top of that it puts mental load
> to admins to make a decision they quite definitively do not care about.
> 
> Let's please not make ours (those having to maintain and those having
> to provide support) and users life more difficult at the same time.

Right, I fully agree for both of your answers above here, we shouldn't 
put the burden on the end user here to make the decision if in the end 
groups should be replaced with location rules anyway.

As said I'd be happy to reduce the amount of compatibility burden for 
users, support and in the code base, so I'll happily implement it that way!

> 
>> 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.
> 
> So does a replacement of the API/UI for groups, as we cannot really
> fully hedge against user manually editing config files that's hardly
> a case I'd look at.
> 
>>
>> 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.
> 
> Just use the group name, if you parse them as affinity rules right away
> no conflict can happen due to them being already included in the state
> and thus any uniqueness check.
> 
> That said, might not really require a named ID's here anyway, having
> a list (array) of rules and a short 127 or 255 max-length free-form
> comment might be more helpful here anyway, as that avoids the need
> to choose an available ID while still allowing to encode hints and
> rationale for certain rule entries.

Right, especially because ids can't be changed but comments can, I'll 
also prefer that much over forcing users to come up with new names for 
rules and not being able to change them (without the delete/create 
cycle). I guess something similar to the user.cfg layout would do it?