Re: [PATCH ha-manager v2 30/40] usage: use add_service to add service usage to nodes

Dominik Rusovac
2026-03-30T08:56:51Z

see comment inline, pls

On Tue Mar 24, 2026 at 7:30 PM CET, Daniel Kral wrote:
> The pve_static (and upcoming pve_dynamic) bindings expose the new
> add_resource(...) method, which allow adding resources in a single call
> with the additional running flag.
>
> The running flag is needed to discriminate starting and started HA
> resources from each other, which is needed to correctly account for HA
> resources for the dynamic load usage implementation in the next patch.
>
> This is because for the dynamic load usage, any HA resource, which is
> scheduled to start by the HA Manager in the same round, will not be
> accounted for in the next call to score_nodes_to_start_resource(...).
> This is not a problem for the static load usage, because there the
> current node usages are derived from the running resources on every
> call already.
>
> Passing only the HA resources' 'state' property is not enough since the
> HA Manager will move any HA resource from the 'request_start' (or
> through other transient states such as 'request_start_balance' and a
> successful 'migrate'/'relocate') into the 'started' state.
>
> This 'started' state is then picked up by the HA resource's LRM, which
> will actually start the HA resource and if successful respond with a
> 'SUCCESS' LRM result. Only then will the HA Manager acknowledges this by
> adding the running flag to the HA resource's state.
>
> Signed-off-by: Daniel Kral <d.kral@proxmox.com>
> ---
> changes v1 -> v2:
> - new!
>
> src/PVE/HA/Usage.pm | 12 +++++++-----
> src/PVE/HA/Usage/Basic.pm | 9 ++++++++-
> src/PVE/HA/Usage/Static.pm | 20 ++++++++++++++------
> 3 files changed, 29 insertions(+), 12 deletions(-)
>
> diff --git a/src/PVE/HA/Usage.pm b/src/PVE/HA/Usage.pm
> index 5f1ac226..822b884c 100644
> --- a/src/PVE/HA/Usage.pm
> +++ b/src/PVE/HA/Usage.pm
> @@ -33,9 +33,8 @@ sub contains_node {
> die "implement in subclass";
> }
>
> -# Logs a warning to $haenv upon failure, but does not die.
> -sub add_service_usage_to_node {
> - my ($self, $nodename, $sid) = @_;
> +sub add_service {
> + my ($self, $sid, $current_node, $target_node, $running) = @_;
>
> die "implement in subclass";
> }
> @@ -47,8 +46,11 @@ sub add_service_usage {
> my $online_nodes = { map { $_ => 1 } $self->list_nodes() };
> my ($current_node, $target_node) = get_used_service_nodes($online_nodes, $sd);
>
> - $self->add_service_usage_to_node($current_node, $sid) if $current_node;
> - $self->add_service_usage_to_node($target_node, $sid) if $target_node;
> + # some usage implementations need to discern whether a service is truly running
> + # a service does only have the 'running' flag in 'started' state
> + my $running = ($sd->{state} eq 'started' && $sd->{running}) || defined($current_node);

This is incorrect, since it would be true whenever state is 'started'.
This is due to how defined($current_node) comes about.

As discussed off-list, the condition should rather be:

my $running = ($sd->{state} eq 'started' && $sd->{running}) || ($sd->{state} ne 'started' && defined($current_node));

A harder to comprehend but more concise option could be:

my $running = ($sd->{state} ne 'started' && defined($current_node)) || $sd->{running};

Had the tests not revealed this yet, it is probably due to the fact that
the sim patches are agnostic to the running flag, which apparently is
not ok. Will fix this.

> +
> + $self->add_service($sid, $current_node, $target_node, $running);
> }
>

[snip]

Reviewed-by: Dominik Rusovac <d.rusovac@proxmox.com>