From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pve-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
	by lore.proxmox.com (Postfix) with ESMTPS id B5D991FF167
	for <inbox@lore.proxmox.com>; Wed, 31 Jul 2024 14:14:53 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
	by firstgate.proxmox.com (Proxmox) with ESMTP id 240D7DB99;
	Wed, 31 Jul 2024 14:14:55 +0200 (CEST)
To: pve-devel@lists.proxmox.com
Date: Wed, 31 Jul 2024 14:14:09 +0200
MIME-Version: 1.0
Message-ID: <mailman.73.1722428094.302.pve-devel@lists.proxmox.com>
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Post: <mailto:pve-devel@lists.proxmox.com>
From: Igor Thaller via pve-devel <pve-devel@lists.proxmox.com>
Precedence: list
Cc: Igor Thaller <igor.thaller@aon.at>
X-Mailman-Version: 2.1.29
X-BeenThere: pve-devel@lists.proxmox.com
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
Subject: [pve-devel] SPAM: [PATCH manager v2] ui: dc summary: fix
 calculation of storage size
Content-Type: multipart/mixed; boundary="===============1746258962993546392=="
Errors-To: pve-devel-bounces@lists.proxmox.com
Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com>

--===============1746258962993546392==
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: <ithaller@praktikum1.proxmox.com>
X-Original-To: pve-devel@lists.proxmox.com
Delivered-To: pve-devel@lists.proxmox.com
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits))
	(No client certificate requested)
	by lists.proxmox.com (Postfix) with ESMTPS id CA2E2C0ECB
	for <pve-devel@lists.proxmox.com>; Wed, 31 Jul 2024 14:14:53 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
	by firstgate.proxmox.com (Proxmox) with ESMTP id A14C7DAD3
	for <pve-devel@lists.proxmox.com>; Wed, 31 Jul 2024 14:14:23 +0200 (CEST)
Received: from praktikum1.proxmox.com (unknown [94.136.29.99])
	by firstgate.proxmox.com (Proxmox) with ESMTP
	for <pve-devel@lists.proxmox.com>; Wed, 31 Jul 2024 14:14:22 +0200 (CEST)
Received: by praktikum1.proxmox.com (Postfix, from userid 10064)
	id 1D0AA500F94; Wed, 31 Jul 2024 14:14:22 +0200 (CEST)
From: Igor Thaller <igor.thaller@aon.at>
To: pve-devel@lists.proxmox.com
subject: SPAM: [PATCH manager v2] ui: dc summary: fix calculation of storage size
Date: Wed, 31 Jul 2024 14:14:09 +0200
Message-Id: <20240731121409.639432-1-igor.thaller@aon.at>
X-Mailer: git-send-email 2.39.2
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-SPAM-LEVEL: Spam detection results:  3
	AWL                    -0.002 Adjusted score from AWL reputation of From: address
	BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
	DMARC_QUAR                0.1 DMARC quarantine policy
	FREEMAIL_FORGED_FROMDOMAIN  0.001 2nd level domains in From and EnvelopeFrom freemail headers are different
	FREEMAIL_FROM           0.001 Sender email is commonly abused enduser mail provider
	HEADER_FROM_DIFFERENT_DOMAINS  0.001 From and EnvelopeFrom 2nd level mail domains are different
	KAM_DMARC_QUARANTINE        3 DKIM has Failed or SPF has failed on the message and the domain has a DMARC quarantine policy
	KAM_DMARC_STATUS         0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
	KAM_LAZY_DOMAIN_SECURITY      1 Sending domain does not have any anti-forgery methods
	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.
	RDNS_NONE               0.793 Delivered to internal network by a host with no rDNS
	SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
	SPF_NONE                0.001 SPF: sender does not publish an SPF Record
	SPOOFED_FREEMAIL        0.001 -
	SPOOFED_FREEMAIL_NO_RDNS  0.001 From SPOOFED_FREEMAIL and no rDNS

The issue is related to the 'Summary' tab under 'Datacenter' inside a
cluster. To get a steady reading of the storage size data, the frontend
requests the '/api2/json/cluster/resources' every three seconds to
retrieve the necessary data to calculate the used and total storage
size.

The problem occurs when a shared storage is defined and a node goes
offline. As the node is not online, it cannot report the shared storage
size (both used and total) back to the other nodes. The order of the
JSON response is not always the same, so it is possible that the offline
node will appear first. Consequently, the frontend will display the
wrong total and used storage. This is because the shared storage data
has both the maximum disk size and the used disk set to zero when the
node is offline. This causes the total and used space data to be
calculated and displayed incorrectly, leading to fluctuations in the
displayed percentage of used disk space.

To fix this, add a conditional check to skip the storage report if its
status is 'unknown' (regardless of if the storage is local or shared).
This prevents the unreliable data from being processed.

Reported-by: Friedrich Weber <f.weber@proxmox.com>
Signed-off-by: Igor Thaller <igor.thaller@aon.at>
---

Notes:
    Changes from v1 -> v2
    * Ignore all storages of status unknown instead of ignoring just shared
      storages with status unknown (thanks Fiona)
    * Move the testing comments to the notes (thanks Fiona)
    * Reword sentence describing the problem
    
    To test these changes, adjust the 'max_requests' variable in the Perl
    script located at '/usr/share/perl5/PVE/Service/pveproxy.pm' to increase
    the likelihood of the error to occur. This makes the storage size
    fluctuations more frequent. Then compare the storage results (both used
    and total sizes) before and after implementing the fix.
    
    Note: Be aware that it takes around one minute for the spike to happen.

 www/manager6/dc/Summary.js | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/www/manager6/dc/Summary.js b/www/manager6/dc/Summary.js
index efb44dae..ae3f9566 100644
--- a/www/manager6/dc/Summary.js
+++ b/www/manager6/dc/Summary.js
@@ -170,6 +170,11 @@ Ext.define('PVE.dc.Summary', {
 			} else if (countedStorage[sid]) {
 			    break;
 			}
+
+			if (data.status === "unknown") {
+			    break;
+			}
+
 			used += data.disk;
 			total += data.maxdisk;
 			countedStorage[sid] = true;
-- 
2.39.2



--===============1746258962993546392==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1746258962993546392==--