From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 929411FF15C for ; Fri, 17 Oct 2025 18:17:50 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 30FA57BE8; Fri, 17 Oct 2025 18:18:10 +0200 (CEST) Mime-Version: 1.0 Date: Fri, 17 Oct 2025 18:18:05 +0200 Message-Id: From: "Daniel Kral" To: "Fiona Ebner" , "Proxmox VE development discussion" X-Mailer: aerc 0.20.0 References: <20250930142021.366529-1-d.kral@proxmox.com> <20250930142021.366529-5-d.kral@proxmox.com> <55218253-d4cf-4846-8d9f-9fc8610a094a@proxmox.com> <8d685bbb-c327-4aed-8f27-f827ecde79c4@proxmox.com> In-Reply-To: <8d685bbb-c327-4aed-8f27-f827ecde79c4@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1760717882189 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.015 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.001 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.001 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.001 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 Subject: Re: [pve-devel] [PATCH ha-manager 1/9] implement static service stats cache X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On Fri Oct 17, 2025 at 12:08 PM CEST, Fiona Ebner wrote: > Am 17.10.25 um 12:02 PM schrieb Fiona Ebner: >> Am 16.10.25 um 5:15 PM schrieb Daniel Kral: >>> On Thu Oct 16, 2025 at 1:12 PM CEST, Fiona Ebner wrote: >>>> Am 30.09.25 um 4:21 PM schrieb Daniel Kral: >>>>> @@ -497,6 +499,25 @@ sub get_datacenter_settings { >>>>> }; >>>>> } >>>>> >>>>> +sub get_static_service_stats { >>>>> + my ($self, $id) = @_; >>>>> + >>>>> + # undef if update_static_service_stats(...) failed before >>>>> + return undef if !defined($self->{static_service_stats}); >>>>> + >>>>> + return $self->{static_service_stats}->{$id} // {}; >>>> >>>> Can't returning '{}' when nothing is there lead to issues down the line? >>>> If we return undef instead, it's consistent with not having anything >>>> cached and the caller will fall back to loading the config. >>> >>> This return value type definitely needs improvement and/or better >>> documentation, but an undef $self->{static_service_stats}->{$id} value >>> indicates that it should fallback to the default value as none of the >>> properties requested by get_guest_config_properties(...) was included in >>> that particular guest config, e.g. no 'cores', 'sockets', and 'memory' >>> properties defined in a VM config. >>> When $self->{static_service_stats} itself is undef, then the static >>> cache couldn't be queried for some reason. >> >> Okay, so get_guest_config_properties() only includes guests that do have >> one of the queried properties explicitly set in its result. Thus, we Yes, I guess that was because of the initial use case of quickly getting all guests which have 'tags' or 'lock' in their config files, which don't need any information about the guests who don't have these. >> cannot distinguish between the cache being created at a time when a >> guest did not exist yet or a guest with none of the queried properties >> explicitly set. If returning {} as a fallback, we get the wrong values >> in the former case, if returning undef as a fallback, we just have to >> explicitly load the config in the latter case. There probably are not >> many setups with many guests without any of the queried properties >> explicitly set, so that is unlikely to hurt performance in practice. > > Or additionally, we could initialize the cache with {} for the guests > that exist at that moment, but do not have any of the queried properties > explicitly set. Right, the cache interface should definitely be decoupled from how it is populated, especially if it might be filled by something other than get_guest_config_properties(...). I think I'll go for the idea for the wrapper over get_guest_config_properties(...), which can quickly set {} explicitly for all the guests (queried from PVE::Cluster's vmlist) without any of the queried properties. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel