Re: [pve-devel] [PATCH perl-rs v3 1/2] pve-rs: resource_scheduling: allow granular usage changes

["Daniel Kral" <d.kral@proxmox.com>]

On Wed Nov 12, 2025 at 11:49 AM CET, Thomas Lamprecht wrote:
> nicer commit subject would be:
>
> pve resource scheduling: allow granular usage changes
>
> Am 27.10.25 um 17:46 schrieb Daniel Kral:
>> Implements a simple bidirectional map to track which service usages have
>> been added to nodes, so that these can be removed later individually.
>> 
>> The `StaticNodeUsage` is newly initialized on every invocation of
>> score_nodes_to_start_service(...) instead of updating the values on
>> every call of `add_service_usage_to_node(...)` to reduce the likelihood
>> of introducing numerical instability caused by floating-point operations
>> done on the `cpu` field.
>> 
>> The StaticServiceUsage is added to the HashMap<> in StaticNodeInfo to
>> reduce unnecessary indirection when summing these values in
>> score_nodes_to_start_service(...).
>> 
>> Signed-off-by: Daniel Kral <d.kral@proxmox.com>
>> Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
>> ---
>> Needs a build dependency bump for
>> librust-proxmox-resource-scheduling-dev and a versioned breaks for
>> pve-ha-manager.
>
> The latter only due to the (signature) change to add_service_usage_to_node, or?
> While versioned breaks can be done, if it's somewhat easy to avoid them it's
> always better to do so, especially as it makes downgrades much easier 
>
> Can we keep backward compat without having to bend to
> much backwards? E.g. adding a new method for the new more granular way while
> keeping add_service_usage_to_node as is, like "record_service_usage_for_node" (or
> just slap a 2 at the end of the method name is also a simple trick that, while not
> beautiful, works and avoids bikeshedding).

I'd go for that route, but the new `sid` parameter is needed to track on
which node a service puts its load on, i.e. where we need to remove it
later. That's information we didn't get before and we unfortunately
cannot make it optional, e.g. shoving it in the already existing
StaticNodeUsage as a Option<_> field. (Haven't tested it yet, but this
shouldn't be an API break for perlmod?)

Another approach would be to allow both the non-granular and granular
behavior to coexist - at least for the 9.x series, even though it might
be a little ugly, it's probably not too bad.

What do you think?


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel