all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: David Riley <d.riley@proxmox.com>
To: Daniel Kral <d.kral@proxmox.com>, pve-devel@lists.proxmox.com
Subject: Re: [PATCH pve-cluster 7/9] cluster: add helpers module with version comparison functions
Date: Mon, 22 Jun 2026 13:44:32 +0200	[thread overview]
Message-ID: <d92e7ab2-b37e-4c7c-94dc-a745439dc4d6@proxmox.com> (raw)
In-Reply-To: <DJFH23L5YG5L.3VH2ZL2MEY3YW@proxmox.com>

On 6/22/26 11:31 AM, Daniel Kral wrote:
> Nice idea for making these helpers more accessible across the packages!
>
> On Thu Jun 11, 2026 at 4:59 PM CEST, David Riley wrote:
>> Move 'version_cmp' and 'pvecfg_min_version' over from qemu-server, to
>> make them more accessible.
>>
>> Originally-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
>> Originally-by: Alexandre Derumier <aderumier@odiso.com>
>> Signed-off-by: David Riley <d.riley@proxmox.com>
>> ---
>>   debian/pve-cluster.install |  1 +
>>   src/PVE/Cluster/Helpers.pm | 51 ++++++++++++++++++++++++++++++++++++++
>>   src/PVE/Cluster/Makefile   |  2 +-
>>   3 files changed, 53 insertions(+), 1 deletion(-)
>>   create mode 100644 src/PVE/Cluster/Helpers.pm
> Hm, I think pve-common might be a more accessible location for such
> helpers and PVE::Cluster::* modules (only Setup and IPCConst at the
> moment) are only used by pve-cluster internally at the moment.

Thanks for taking a look.
My initial thought was to keep this closer to the caller from patch 8 [0]  to make it
more readable.
But you are right it would fit better into pve-common.
I'll move it in v2.

[0] https://lore.proxmox.com/pve-devel/20260611145935.147788-9-d.riley@proxmox.com/

>> diff --git a/debian/pve-cluster.install b/debian/pve-cluster.install
>> index f66cd06..46d40c4 100644
>> --- a/debian/pve-cluster.install
>> +++ b/debian/pve-cluster.install
>> @@ -5,4 +5,5 @@ usr/lib/
>>   usr/share/man/man8/pmxcfs.8
>>   usr/share/perl5/PVE/Cluster.pm
>>   usr/share/perl5/PVE/Cluster/IPCConst.pm
>> +usr/share/perl5/PVE/Cluster/Helpers.pm
>>   usr/share/perl5/PVE/IPCC.pm
>> diff --git a/src/PVE/Cluster/Helpers.pm b/src/PVE/Cluster/Helpers.pm
>> new file mode 100644
>> index 0000000..a4b41c9
>> --- /dev/null
>> +++ b/src/PVE/Cluster/Helpers.pm
>> @@ -0,0 +1,51 @@
>> +package PVE::Cluster::Helpers;
>> +
>> +use strict;
>> +use warnings;
> nit: new modules could already be introduced with 'use v5.36' so you can
>       use subroutine signatures :) [0]
>
> [0] https://perldoc.perl.org/perlsub#Signatures

Thanks for the heads up. Will adapt this in v2.

>> +
>> +use JSON;
>> +
>> +use base 'Exporter';
>> +our @EXPORT_OK = qw(pvecfg_min_version assert_min_cluster_version version_cmp);
>> +
>> +sub pvecfg_min_version {
>> +    my ($verstr, $major, $minor, $release) = @_;
>> +
>> +    return 0 if !$verstr;
>> +
>> +    if ($verstr =~ m/^(\d+)\.(\d+)(?:[.-](\d+))?/) {
>> +        return 1 if version_cmp($1, $major, $2, $minor, $3 // 0, $release) >= 0;
>> +        return 0;
>> +    }
>> +
>> +    die "internal error: cannot check version of invalid string '$verstr'";
>> +}
>> +
>> +# gets in pairs the versions you want to compares, i.e.:
>> +# ($a-major, $b-major, $a-minor, $b-minor, $a-extra, $b-extra, ...)
>> +# returns 0 if same, -1 if $a is older than $b, +1 if $a is newer than $b
>> +sub version_cmp {
>> +    my @versions = @_;
>> +
>> +    my $size = scalar(@versions);
>> +
>> +    return 0 if $size == 0;
>> +
>> +    if ($size & 1) {
>> +        my (undef, $fn, $line) = caller(0);
>> +        die "cannot compare odd count of versions, called from $fn:$line\n";
>> +    }
>> +
>> +    for (my $i = 0; $i < $size; $i += 2) {
>> +        my ($left, $right) = splice(@versions, 0, 2);
>> +        $left //= 0;
>> +        $right //= 0;
>> +
>> +        return 1 if $left > $right;
>> +        return -1 if $left < $right;
>> +    }
>> +    return 0;
>> +}
> Preexisting, but as this will be used by assert_min_cluster_version(...)
> in the next patch: the key-value pair 'version-info' contains the
> broadcasted pve-manager version of each node.
>
> For the pve-manager we sometimes use another revision number in addition
> to the usual version triple in the version string, especially around the
> time of a new major version (e.g. [1]).
>
> After the major, minor and release/patch version is compared, the part
> after should be compared lexically [2]. That means, that e.g. 9.0.0 is a
> newer version than 9.0.0~22 as 9.0.0 is lexically first.
>
> This is not needed right now, but might be worth to keep an eye on
> already so this doesn't break especially for features that require
> gatekeeping right around the release of a new major version.
>
> [1] https://git.proxmox.com/?p=pve-manager.git;a=blob;f=debian/changelog;h=a792b2c51800b4e4d8c60b8b4235bbc85386eba6;hb=HEAD#l1039
> [2] https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version
>
Good catch. Since qemu-server currently relies on this exact implementation, I'd prefer
not touching the underlying logic in this patch to avoid regressions.
I will however add a comment to assert_min_cluster_version(...) mentioning the current
limitation.

>> [...]




  reply	other threads:[~2026-06-22 11:44 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-11 14:59 [PATCH access-control/cluster/manager/network/qemu-server 0/9] fix #7294: pool: add SDN VNets as pool members David Riley
2026-06-11 14:59 ` [PATCH pve-manager 1/9] ui: replace var with let to match style guide for variable declaration David Riley
2026-06-11 14:59 ` [PATCH pve-manager 2/9] fix #7294: api: pool: add SDN VNets as pool members David Riley
2026-06-22 11:20   ` Daniel Kral
2026-06-22 13:37     ` David Riley
2026-06-24  7:32       ` Daniel Kral
2026-06-24 12:06         ` David Riley
2026-06-11 14:59 ` [PATCH pve-manager 3/9] fix #7294: ui: " David Riley
2026-06-11 14:59 ` [PATCH pve-access-control 4/9] fix #7294: acl: " David Riley
2026-06-11 14:59 ` [PATCH pve-network 5/9] fix #7294: sdn: register api formats for zones and vnets David Riley
2026-06-12 12:18   ` Gabriel Goller
2026-06-12 12:51     ` David Riley
2026-06-12 13:46       ` Gabriel Goller
2026-06-12 14:17         ` David Riley
2026-06-11 14:59 ` [PATCH pve-network 6/9] fix #7294: sdn: vnet: update pool members on vnet migration and deletion David Riley
2026-06-11 16:21   ` Gabriel Goller
2026-06-12  6:37     ` David Riley
2026-06-12  8:41       ` Gabriel Goller
2026-06-11 14:59 ` [PATCH pve-cluster 7/9] cluster: add helpers module with version comparison functions David Riley
2026-06-22  9:31   ` Daniel Kral
2026-06-22 11:44     ` David Riley [this message]
2026-06-11 14:59 ` [PATCH pve-cluster 8/9] fix #7294: cluster: helpers: add cluster-wide version assertion David Riley
2026-06-22  9:42   ` Daniel Kral
2026-06-22 11:53     ` David Riley
2026-06-11 14:59 ` [PATCH qemu-server 9/9] fix #7294: helpers: use cluster-wide version helper David Riley
2026-06-19 10:01 ` [PATCH access-control/cluster/manager/network/qemu-server 0/9] fix #7294: pool: add SDN VNets as pool members Jakob Klocker
2026-06-19 11:12   ` David Riley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d92e7ab2-b37e-4c7c-94dc-a745439dc4d6@proxmox.com \
    --to=d.riley@proxmox.com \
    --cc=d.kral@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal