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?
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
