all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: "Max Carrara" <m.carrara@proxmox.com>
To: "Proxmox VE development discussion" <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH storage] volume import: assume target API version is at least 9
Date: Tue, 02 Jul 2024 19:14:34 +0200	[thread overview]
Message-ID: <D2F80HY0Q15L.2BNN7L0AK0UI@proxmox.com> (raw)
In-Reply-To: <20240610090415.13057-1-f.ebner@proxmox.com>

On Mon Jun 10, 2024 at 11:04 AM CEST, Fiona Ebner wrote:
> The storage API version has been bumped to at least 9 since
> libpve-storage = 7.0-4. If the source node is on Proxmox VE 8, where
> this change will come in, then the target node can be assumed to be
> running either Proxmox VE 8 or, during upgrade, the latest version of
> Proxmox VE 7.4, so it's safe to assume a storage API version of at
> least 9 in all cases.
>
> As reported by Maximiliano, the fact that the 'apiinfo' call was
> guarded with a quiet eval could lead to strange errors for replication
> on a customer system where an SSH connection could not always be
> established, because the target's API version would fall back to 1.
> Because of that, the '-base' argument would be missing for the import
> call on the target which would in turn lead to an error about the
> target ZFS volume already existing (rather than doing an incremental
> sync).
>
> Reported-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>

Wasn't able to test this at the moment yet (please holler at me if you
need me to), but these changes are pretty straightforward anyway.

I completely agree with all of these changes; LGTM.

Reviewed-by: Max Carrara <m.carrara@proxmox.com>

> ---
>  src/PVE/Storage.pm | 18 ++++++------------
>  1 file changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/src/PVE/Storage.pm b/src/PVE/Storage.pm
> index f19a115..bee2361 100755
> --- a/src/PVE/Storage.pm
> +++ b/src/PVE/Storage.pm
> @@ -709,7 +709,7 @@ sub storage_migrate_snapshot {
>  }
>  
>  my $volume_import_prepare = sub {
> -    my ($volid, $format, $path, $apiver, $opts) = @_;
> +    my ($volid, $format, $path, $opts) = @_;
>  
>      my $base_snapshot = $opts->{base_snapshot};
>      my $snapshot = $opts->{snapshot};
> @@ -724,11 +724,11 @@ my $volume_import_prepare = sub {
>      if ($migration_snapshot) {
>  	push @$recv, '-delete-snapshot', $snapshot;
>      }
> -    push @$recv, '-allow-rename', $allow_rename if $apiver >= 5;
> +    push @$recv, '-allow-rename', $allow_rename;
>  
>      if (defined($base_snapshot)) {
>  	# Check if the snapshot exists on the remote side:
> -	push @$recv, '-base', $base_snapshot if $apiver >= 9;
> +	push @$recv, '-base', $base_snapshot;
>      }
>  
>      return $recv;
> @@ -814,12 +814,7 @@ sub storage_migrate {
>  	$import_fn = "tcp://$net";
>      }
>  
> -    my $target_apiver = 1; # if there is no apiinfo call, assume 1
> -    my $get_api_version = [@$ssh, 'pvesm', 'apiinfo'];
> -    my $match_api_version = sub { $target_apiver = $1 if $_[0] =~ m!^APIVER (\d+)$!; };
> -    eval { run_command($get_api_version, logfunc => $match_api_version); };
> -
> -    my $recv = [ @$ssh, '--', $volume_import_prepare->($target_volid, $format, $import_fn, $target_apiver, $opts)->@* ];
> +    my $recv = [ @$ssh, '--', $volume_import_prepare->($target_volid, $format, $import_fn, $opts)->@* ];
>  
>      my $new_volid;
>      my $pattern = volume_imported_message(undef, 1);
> @@ -911,8 +906,7 @@ sub storage_migrate {
>  	    run_command($cmds, logfunc => $match_volid_and_log);
>  	}
>  
> -	die "unable to get ID of the migrated volume\n"
> -	    if !defined($new_volid) && $target_apiver >= 5;
> +	die "unable to get ID of the migrated volume\n" if !defined($new_volid);
>      };
>      my $err = $@;
>      if ($opts->{migration_snapshot}) {
> @@ -1961,7 +1955,7 @@ sub volume_import_start {
>      my $info = IO::File->new();
>  
>      my $unix = $opts->{unix} // "/run/pve/storage-migrate-$vmid.$$.unix";
> -    my $import = $volume_import_prepare->($volid, $format, "unix://$unix", APIVER, $opts);
> +    my $import = $volume_import_prepare->($volid, $format, "unix://$unix", $opts);
>  
>      unlink $unix;
>      my $cpid = open3($input, $info, $info, @$import)



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


  reply	other threads:[~2024-07-02 17:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-10  9:04 Fiona Ebner
2024-07-02 17:14 ` Max Carrara [this message]
2024-07-03 12:26 ` [pve-devel] applied: " Fiona Ebner
2024-07-04  9:52 ` [pve-devel] " Thomas Lamprecht
2024-07-04 10:28   ` Fiona Ebner
2024-07-04 11:51     ` Thomas Lamprecht
2024-07-04 12:11       ` Fiona Ebner
2024-07-04 17:45         ` Thomas Lamprecht
2024-07-05  8:22           ` Fiona Ebner
2024-07-25 12:38             ` Thomas Lamprecht
2024-07-05  7:45         ` Thomas Lamprecht

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=D2F80HY0Q15L.2BNN7L0AK0UI@proxmox.com \
    --to=m.carrara@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