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

[Thomas Lamprecht]

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.

> 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.