* [pve-devel] [PATCH storage] api: fix get content call for volumes
@ 2023-03-06 9:37 Christian Ebner
2023-03-06 10:17 ` Fiona Ebner
0 siblings, 1 reply; 5+ messages in thread
From: Christian Ebner @ 2023-03-06 9:37 UTC (permalink / raw)
To: pve-devel
`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);
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};
}
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;
}
sub volume_resize {
diff --git a/PVE/Storage/ZFSPoolPlugin.pm b/PVE/Storage/ZFSPoolPlugin.pm
index 9fbd149..90fc576 100644
--- a/PVE/Storage/ZFSPoolPlugin.pm
+++ b/PVE/Storage/ZFSPoolPlugin.pm
@@ -452,7 +452,7 @@ sub volume_size_info {
my $attr = $format eq 'subvol' ? 'refquota' : 'volsize';
my $value = $class->zfs_get_properties($scfg, $attr, "$scfg->{pool}/$vname");
if ($value =~ /^(\d+)$/) {
- return $1;
+ return wantarray ? ($1, $format, 0, undef) : $1;
}
die "Could not get zfs volume size\n";
--
2.30.2
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [pve-devel] [PATCH storage] api: fix get content call for volumes
2023-03-06 9:37 [pve-devel] [PATCH storage] api: fix get content call for volumes Christian Ebner
@ 2023-03-06 10:17 ` Fiona Ebner
2023-03-06 10:36 ` Christian Ebner
0 siblings, 1 reply; 5+ messages in thread
From: Fiona Ebner @ 2023-03-06 10:17 UTC (permalink / raw)
To: pve-devel, c.ebner
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.
>
> 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.
> }
>
> sub volume_resize {
> diff --git a/PVE/Storage/ZFSPoolPlugin.pm b/PVE/Storage/ZFSPoolPlugin.pm
> index 9fbd149..90fc576 100644
> --- a/PVE/Storage/ZFSPoolPlugin.pm
> +++ b/PVE/Storage/ZFSPoolPlugin.pm
> @@ -452,7 +452,7 @@ sub volume_size_info {
> my $attr = $format eq 'subvol' ? 'refquota' : 'volsize';
> my $value = $class->zfs_get_properties($scfg, $attr, "$scfg->{pool}/$vname");
> if ($value =~ /^(\d+)$/) {
> - return $1;
> + return wantarray ? ($1, $format, 0, undef) : $1;
> }
>
> die "Could not get zfs volume size\n";
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [pve-devel] [PATCH storage] api: fix get content call for volumes
2023-03-06 10:17 ` Fiona Ebner
@ 2023-03-06 10:36 ` Christian Ebner
2023-03-06 10:52 ` Fiona Ebner
0 siblings, 1 reply; 5+ messages in thread
From: Christian Ebner @ 2023-03-06 10:36 UTC (permalink / raw)
To: Fiona Ebner, pve-devel
> 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?
>
> >
> > 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?
>
> > }
> >
> > sub volume_resize {
> > diff --git a/PVE/Storage/ZFSPoolPlugin.pm b/PVE/Storage/ZFSPoolPlugin.pm
> > index 9fbd149..90fc576 100644
> > --- a/PVE/Storage/ZFSPoolPlugin.pm
> > +++ b/PVE/Storage/ZFSPoolPlugin.pm
> > @@ -452,7 +452,7 @@ sub volume_size_info {
> > my $attr = $format eq 'subvol' ? 'refquota' : 'volsize';
> > my $value = $class->zfs_get_properties($scfg, $attr, "$scfg->{pool}/$vname");
> > if ($value =~ /^(\d+)$/) {
> > - return $1;
> > + return wantarray ? ($1, $format, 0, undef) : $1;
> > }
> >
> > die "Could not get zfs volume size\n";
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [pve-devel] [PATCH storage] api: fix get content call for volumes
2023-03-06 10:36 ` Christian Ebner
@ 2023-03-06 10:52 ` Fiona Ebner
2023-03-06 10:56 ` Christian Ebner
0 siblings, 1 reply; 5+ messages in thread
From: Fiona Ebner @ 2023-03-06 10:52 UTC (permalink / raw)
To: Christian Ebner, pve-devel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [pve-devel] [PATCH storage] api: fix get content call for volumes
2023-03-06 10:52 ` Fiona Ebner
@ 2023-03-06 10:56 ` Christian Ebner
0 siblings, 0 replies; 5+ messages in thread
From: Christian Ebner @ 2023-03-06 10:56 UTC (permalink / raw)
To: Fiona Ebner, pve-devel
> 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!
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-03-06 10:56 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-06 9:37 [pve-devel] [PATCH storage] api: fix get content call for volumes 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 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.