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 [IPv6:2a01:7e0:0:424::9])
by lore.proxmox.com (Postfix) with ESMTPS id 153E51FF164
for <inbox@lore.proxmox.com>; Fri, 23 May 2025 18:36:07 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id B3CEF1EB56;
Fri, 23 May 2025 18:36:08 +0200 (CEST)
Message-ID: <91fe7ca4-a07b-4326-8587-f4e08f1ecd5e@proxmox.com>
Date: Fri, 23 May 2025 18:35:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: pve-devel@lists.proxmox.com
References: <20250523160029.404400-1-a.lauterer@proxmox.com>
<20250523160029.404400-3-a.lauterer@proxmox.com>
From: Aaron Lauterer <a.lauterer@proxmox.com>
In-Reply-To: <20250523160029.404400-3-a.lauterer@proxmox.com>
X-SPAM-LEVEL: Spam detection results: 0
AWL -0.030 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 cluster-pve8 2/2] status: handle new pve9-
metrics update data
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
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/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: pve-devel-bounces@lists.proxmox.com
Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com>
On 2025-05-23 18:00, Aaron Lauterer wrote:
> For PVE9 there will be additional fields in the metrics that are
> collected. The new columns/fields are added at the end of the current
> ones. Therefore, if we get the new format, we need to cut it.
>
> Paths to rrd filenames needed to be set manually to 'pve2-...' and will
> use the 'node' part instead of the full key, as that could also be
> 'pve9-...' which does not exists.
since it pops up for the first time in the series here: I currently
chose 'pve9-' as prefix for the metric keys, following what we used so
far AFAICT -> PVE version when it was introduced
.
But we could also think about changing it to something like
'pve-{node,storage,vm}-{version}' as that could make it easier to change
the code to also handle other new and right now unknown formats in the
futures if we always only append new columns/fields.
But I am not exactly sure how we should do the versioning because the
current approach in the status.c is to strncmp a fixed length of the
full key and that would be problematic if we use the following examples:
pve-vm-9
pve-vm-10
when do we check for 8 or 9 character long strings? There might be a
nice way to do this, as in, checking until we reach the separating /.
2 digits with leading 0 could be one approach. But if we also add minor
PVE versions, well that makes it more complicated.
Or we could switch to it being just an integer that will be increased
when we add more data.
Just to throw out some ideas :)
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel