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 51C831FF16F for ; Thu, 2 Jan 2025 11:48:02 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E80EBA187; Thu, 2 Jan 2025 11:47:55 +0100 (CET) Message-ID: <10a36f74-e682-4495-bf8a-91ddd3b8e59c@proxmox.com> Date: Thu, 2 Jan 2025 11:47:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Wolfgang Bumiller References: <20240806130007.239356-1-l.wagner@proxmox.com> <20240806130007.239356-7-l.wagner@proxmox.com> Content-Language: de-AT, en-US From: Lukas Wagner In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL 0.009 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: [pdm-devel] [PATCH proxmox v4 06/20] rrd: try to load database if not already present in cache X-BeenThere: pdm-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Datacenter Manager development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox Datacenter Manager development discussion Cc: pdm-devel@lists.proxmox.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pdm-devel-bounces@lists.proxmox.com Sender: "pdm-devel" On 2024-09-19 11:30, Wolfgang Bumiller wrote: > This actually needs to be opt-in (or opt-out). > The API calls to query RRD data will now *always succeed* even if > specifying a wrong node name for instance. > > $ proxmox-datacenter-manager-client pve node rrddata pve8a anonexistingnodethatwillneverexist MAX hour > [] > Finally got around to taking a look at this, sorry for the delay. Fixing this is actually quite tricky. Consider the following scenario: - add a new remote (with nodes A and B) - query rrddata for node 'A' *before* the first metric collection round In this case, we probably want to return an empty response (no data yet). However, if we - query rrddata for node 'C' (which does not exist) we would like to return an error, because the node is not known. However, it is tricky to distinguish between these two cases. Of course, we could retrieve a list of all nodes via the API and differentiate the cases based on that, but even then we still can have a race condition where a new node was added to the PVE cluster but we did fetch any metric data for it yet. Also, we don't want do do an API request to the remote each and every time we query RRD data. If we add caching for the list of known nodes, we increase the risk for the aforementioned race condition. TBH I'd just leave it as is, returning an empty reponse instead of an error seems like a cosmetical issue to me. The number of users using the this API for custom metric visualization is probably very low. What do you think? -- - Lukas _______________________________________________ pdm-devel mailing list pdm-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel