Am 25.03.25 um 16:12 schrieb Daniel Kral: > | Canonicalization > ---------- > > Additionally, colocation rules are currently simplified as follows: > > - If there are multiple positive colocation rules with common services > and the same strictness, these are merged to a single positive > colocation rule.
Do you intend to do that when writing the configuration file? I think rules are better left unmerged from a user perspective. For example: - services 1, 2 and 3 should strictly stay together, because of reason A - services 1 and 3 should strictly stay together, because of different reason B Another scenario might be that the user is currently in the process of editing some rules one-by-one and then it might also be surprising if something is auto-merged. You can of course always dynamically merge them when doing the computation for the node selection. In the same spirit, a comment field for each rule where the user can put the reason might be nice to have. Another question is if we should allow enabling/disabling rules. Comment and enabling can of course always be added later. I'm just not sure we should start out with the auto-merging of rules. > | Inference rules > ---------- > > There are currently no inference rules implemented for the RFC, but > there could be potential to further simplify some code paths in the > future, e.g. a positive colocation rule where one service is part of a > restricted HA group makes the other services in the positive colocation > rule a part of this HA group as well. If the rule is strict. If we do this I think it should only happen dynamically for the node selection too. > Comment about HA groups -> Location Rules > ----------------------------------------- > > This part is not really part of the patch series, but still worth for an > on-list discussion. > > I'd like to suggest to also transform the existing HA groups to location > rules, if the rule concept turns out to be a good fit for the colocation > feature in the HA Manager, as HA groups seem to integrate quite easily > into this concept. > > This would make service-node relationships a little more flexible for > users and we'd be able to have both configurable / visible in the same > WebUI view, API endpoint, and configuration file. Also, some code paths > could be a little more consise, e.g. checking changes to constraints and > canonicalizing the rules config. > > The how should be rather straightforward for the obvious use cases: > > - Services in unrestricted HA groups -> Location rules with the nodes of > the HA group; We could either split each node priority group into > separate location rules (with each having their score / weight) or > keep the input format of HA groups with a list of > `<node>(:<priority>)` in each rule > > - Services in restricted HA groups -> Same as above, but also using > either `+inf` for a mandatory location rule or `strict` property > depending on how we decide on the colocation rule properties I'd prefer having a 'strict' property, as that is orthogonal to the priorities and that aligns it with what you propose for the colocation rules. > This would allow most of the use cases of HA groups to be easily > migratable to location rules. We could also keep the inference of the > 'default group' for unrestricted HA groups (any node that is available > is added as a group member with priority -1). Nodes can change, so adding them explicitly will mean it can get outdated. This should be implicit/done dynamically. > The only thing that I'm unsure about this, is how we would migrate the > `nofailback` option, since this operates on the group-level. If we keep > the `<node>(:<priority>)` syntax and restrict that each service can only > be part of one location rule, it'd be easy to have the same flag. If we > go with multiple location rules per service and each having a score or > weight (for the priority), then we wouldn't be able to have this flag > anymore. I think we could keep the semantic if we move this flag to the > service config, but I'm thankful for any comments on this. My gut feeling is that going for a more direct mapping, i.e. each location rule represents one HA group, is better. The nofailback flag can still apply to a given location rule I think? For a given service, if a higher-priority node is online for any location rule the service is part of, with nofailback=0, it will get migrated to that higher-priority node. It does make sense to have a given service be part of only one location rule then though, since node priorities can conflict between rules. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
