From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 43D501FF13C for ; Thu, 19 Mar 2026 15:08:16 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 7889B1FADF; Thu, 19 Mar 2026 15:08:29 +0100 (CET) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 19 Mar 2026 15:07:55 +0100 Message-Id: Subject: Re: [RFC ha-manager 12/21] env: pve2: implement dynamic node and service stats From: "Daniel Kral" To: "Thomas Lamprecht" , X-Mailer: aerc 0.21.0-38-g7088c3642f2c-dirty References: <20260217141437.584852-1-d.kral@proxmox.com> <20260217141437.584852-26-d.kral@proxmox.com> <20260318165820.81517-3-t.lamprecht@proxmox.com> In-Reply-To: <20260318165820.81517-3-t.lamprecht@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1773929232553 X-SPAM-LEVEL: Spam detection results: 0 AWL -1.017 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.408 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.819 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.903 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: F2F5BGJY2DT243ZFFEMUE2P624T57WYQ X-Message-ID-Hash: F2F5BGJY2DT243ZFFEMUE2P624T57WYQ X-MailFrom: d.kral@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed Mar 18, 2026 at 5:54 PM CET, Thomas Lamprecht wrote: > On Tue, 17 Feb 2026, Daniel Kral wrote: >> --- a/src/PVE/HA/Env/PVE2.pm >> +++ b/src/PVE/HA/Env/PVE2.pm >> @@ -564,6 +564,30 @@ sub get_static_service_stats { >> [...] >> + # FIXME $rrdentry->[5] is the problematic $d->{cpus} from vmsta= tus >> + my $maxcpu =3D ($rrdentry->[5] || 0.0) + 0.0; >> + >> + $stats->{$sid}->{usage} =3D { >> + maxcpu =3D> $maxcpu, >> + cpu =3D> (($rrdentry->[6] || 0.0) + 0.0) * $maxcpu, >> + maxmem =3D> int($rrdentry->[7] || 0), >> + mem =3D> int($rrdentry->[8] || 0), >> + }; > > Either resolve this FIXME or explain in the commit message why it is > acceptable for now. Will do, to clarify here already: 'problematic' is the wrong word here. $rrdentry->[5] is capped at the maximum cpu count of the node, so it actually helps us at keeping the value at a reasonable value for the usage statistics. This is not done for the maxmem field though. Keep in mind that we don't do that for the static service stats right now as these are only read and parsed from the guest configs and the helpers don't cap it there at all. This goes a bit beyond this series, but we should evaluate whether we should cap these resource stats in the scheduler in general to the node's max stats in the future as it never can go beyond that. > > Also, would be nice to use constants for these RRD array indices [4] > through [8], to make them less like some magic numbers and reduce > error potential, as these can effect scheduling decisions dramatically > I'd immagine. Will do so + a constant for the status entry index used in get_cluster_service_stats() as well. I'll put them in PVE::HA::Env::PVE2 with a comment where they are derived from for now, but would probably be nice in the future that these constants are declared where they fixed, i.e., the pvestatd service, but don't want to bloat this series for that.