From: Christian Ebner <c.ebner@proxmox.com>
To: Fiona Ebner <f.ebner@proxmox.com>, pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] [PATCH storage] api: fix get content call for volumes
Date: Mon, 6 Mar 2023 11:56:56 +0100 (CET) [thread overview]
Message-ID: <199729762.3362.1678100216603@192.168.2.153> (raw)
In-Reply-To: <fb225072-aff3-d603-0ba0-83d8392602a7@proxmox.com>
> On 06.03.2023 11:52 CET Fiona Ebner <f.ebner@proxmox.com> wrote:
>
>
> Am 06.03.23 um 11:36 schrieb Christian Ebner:
> >
> >> On 06.03.2023 11:17 CET Fiona Ebner <f.ebner@proxmox.com> wrote:
> >>
> >>
> >> Am 06.03.23 um 10:37 schrieb Christian Ebner:
> >>> `pvesh get /nodes/{node}/storage/{storage}/content/{volume}` failed for
> >>> several storage types, because the respective storage plugins returned
> >>> only the volumes `size` on `volume_size_info` calls, while also the format
> >>> is required.
> >>>
> >>> This patch fixes the issue by returning also `format` and `used`, the
> >>> latter also being a non-optional return value for the api call.
> >>>
> >>> The issue was reported in the forum:
> >>> https://forum.proxmox.com/threads/pvesh-get-nodes-node-storage-storage-content-volume-returns-error.123747/
> >>>
> >>> Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
> >>> ---
> >>> PVE/API2/Storage/Content.pm | 2 +-
> >>> PVE/Storage/ISCSIDirectPlugin.pm | 2 +-
> >>> PVE/Storage/RBDPlugin.pm | 2 +-
> >>> PVE/Storage/ZFSPoolPlugin.pm | 2 +-
> >>> 4 files changed, 4 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/PVE/API2/Storage/Content.pm b/PVE/API2/Storage/Content.pm
> >>> index fe0ad4a..36433ba 100644
> >>> --- a/PVE/API2/Storage/Content.pm
> >>> +++ b/PVE/API2/Storage/Content.pm
> >>> @@ -324,7 +324,7 @@ __PACKAGE__->register_method ({
> >>>
> >>> my $path = PVE::Storage::path($cfg, $volid);
> >>> my ($size, $format, $used, $parent) = PVE::Storage::volume_size_info($cfg, $volid);
> >>> - die "volume_size_info on '$volid' failed\n" if !($format && $size);
> >>> + die "volume_size_info on '$volid' failed\n" if !($format && $size && $used);
> >>
> >> This change should be it's own patch and I think it's wrong. Can't $used
> >> be zero and valid, e.g. for a newly created empty image? You'd either
> >> need to use defined($used) or leave it as-is, i.e. not failing and
> >> defaulting to 0 when $used is undef. Even with the defined() check, this
> >> would break an external plugin that doesn't return $used. While I guess
> >> that could be tolerated, we might do it together with the next APIAGE
> >> reset and document that volume_size_info explicitly requires it.
> >
> > Yes, this was a really sloppy oversight, only added after my testing. On the other hand, should the API call fail for volumes reporting $size = 0 here? Is this intentional or should this also be fixed?
>
> I don't think there are valid cases where $size is 0, or?
>
> >>
> >>>
> >>> my $entry = {
> >>> path => $path,
> >>> diff --git a/PVE/Storage/ISCSIDirectPlugin.pm b/PVE/Storage/ISCSIDirectPlugin.pm
> >>> index 9777969..eb329d4 100644
> >>> --- a/PVE/Storage/ISCSIDirectPlugin.pm
> >>> +++ b/PVE/Storage/ISCSIDirectPlugin.pm
> >>> @@ -208,7 +208,7 @@ sub volume_size_info {
> >>> my $vollist = iscsi_ls($scfg,$storeid);
> >>> my $info = $vollist->{$storeid}->{$volname};
> >>>
> >>> - return $info->{size};
> >>> + return wantarray ? ($info->{size}, 'raw', 0, undef) : $info->{size};
> >>
> >> Why return 0 for $used? Doesn't the API call then fail because of the
> >> check you added above?
> >>
> >>> }
> >>>
> >>> sub volume_resize {
> >>> diff --git a/PVE/Storage/RBDPlugin.pm b/PVE/Storage/RBDPlugin.pm
> >>> index 9047504..e69c44c 100644
> >>> --- a/PVE/Storage/RBDPlugin.pm
> >>> +++ b/PVE/Storage/RBDPlugin.pm
> >>> @@ -730,7 +730,7 @@ sub volume_size_info {
> >>>
> >>> my ($vtype, $name, $vmid) = $class->parse_volname($volname);
> >>> my ($size, undef) = rbd_volume_info($scfg, $storeid, $name);
> >>> - return $size;
> >>> + return wantarray ? ($size, 'raw', 0, undef) : $size;
> >>
> >> Also, always returning undef for the parent is also not correct for RBD
> >> and ZFS.
> >
> > What's the cheapest way here to get the parent for ZFS and RBD?
>
> I think parse_volname() should already give it to you. It's encoded in
> the volume ID.
Okay, I will have a look and incorporate this in a version 2, thank you for the input!
prev parent reply other threads:[~2023-03-06 10:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-06 9:37 Christian Ebner
2023-03-06 10:17 ` Fiona Ebner
2023-03-06 10:36 ` Christian Ebner
2023-03-06 10:52 ` Fiona Ebner
2023-03-06 10:56 ` Christian Ebner [this message]
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=199729762.3362.1678100216603@192.168.2.153 \
--to=c.ebner@proxmox.com \
--cc=f.ebner@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.