From: Fiona Ebner <f.ebner@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
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: Thu, 4 Jul 2024 12:28:41 +0200 [thread overview]
Message-ID: <5b972ac1-42d1-4f53-b5c4-8423352f5e09@proxmox.com> (raw)
In-Reply-To: <5e7e6f52-7ba0-42cd-a771-2261acd0dc36@proxmox.com>
Am 04.07.24 um 11:52 schrieb Thomas Lamprecht:
> Am 10/06/2024 um 11:04 schrieb Fiona Ebner:
>> 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.
>
> it's fine by me that this was applied, but can we somehow assert this
> assumption with an early `die if $apiver < 7` ? (maybe don't die if the
> apiver could not be queried/parsed, i.e. is undef, if there are
> legitimate situations where this can happen).
>
Why version 7? We'd need to distinguish between there not being an
apiinfo API call and other errors. The previous code did just continue
if not being able to query (punting version to 1) and that lead to the
very issue reported by Maximiliano.
> While just one major release difference might be seen as enough, we still
> have users that are doing some more funky stuff on upgrades of clusters,
> so if it's somewhat easy to assert the assumption, doing so can
> definitively only help to improve UX.
Well, we'd have to put back in the apiinfo call for that. If using
version 9 for the check instead of 7, the only thing it would do is die
early when replicating back from an upgraded node to a node with
libpve-storage < 7.0-4
For offline guest disk migration, the base_snapshot check doesn't matter
so the only thing the check would catch is migrating back to a node with
api version < 5 which means libpve-storage-perl < 6.1-6.
I'd rather have the code cleaner than very slightly improve UX for users
running ancient versions.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2024-07-04 10:28 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
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 [this message]
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=5b972ac1-42d1-4f53-b5c4-8423352f5e09@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox