[pve-devel] [PATCH manager] pvesh: decode streamed responses

[pve-devel] [PATCH manager] pvesh: decode streamed responses

[Christoph Heiss]

This allows to use `pvesh` on endpoints like /nodes/{node}/journal,
which return streamed (and possibly gzip'd) responses.

Currently, e.g. `pvesh get /nodes/localhost/journal --lastentries 10`
fails with:

  gzip: stdout: Broken pipe
  got hash object, but result schema specified array!

Using e.g. `--output-format yaml` resulted in:

  ---
  download:
    content-encoding: gzip
    content-type: application/json
    fh: &1 !!perl/ref
      =: *1
    stream: 1

  gzip: stdout: Broken pipe
  Failed to write

This is due the API call returning a "download" object (as seen above),
which contains (among some other things) a file handle to read the
response from.

With this patch, the response from such endpoints is now correctly read
and displayed. Only handles combinations of `Content-Encoding` == 'gzip'
and either 'text/plain' or 'application/json' for `Content-Type`.

This tries to mimic the behavior of the API server implementation when
encountering `download` objects.

Tested this with all four output formats 'text', 'json', 'json-pretty'
and 'yaml', as well as "cross-node" in a local test cluster.

Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
---
As far as I could see (aka. grep for it), the only two endpoints which
implement this are /nodes/{node}/journal and
/nodes/{node}/tasks/{upid}/log, latter one only with `--download 1`
set.

 PVE/CLI/pvesh.pm | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/PVE/CLI/pvesh.pm b/PVE/CLI/pvesh.pm
index 9acf292a..764d47a2 100755
--- a/PVE/CLI/pvesh.pm
+++ b/PVE/CLI/pvesh.pm
@@ -15,6 +15,7 @@ use PVE::CLIHandler;
 use PVE::API2Tools;
 use PVE::API2;
 use JSON;
+use IO::Uncompress::Gunzip qw(gunzip);

 use base qw(PVE::CLIHandler);

@@ -281,6 +282,37 @@ my $cond_add_standard_output_properties = sub {
     return PVE::RESTHandler::add_standard_output_properties($props, $keys);
 };

+my $handle_streamed_response = sub {
+    my ($download) = @_;
+    my ($fh, $path, $encoding, $type) =
+	$download->@{'fh', 'path', 'content-encoding', 'content-type'};
+
+    die "{download} returned but neither fh nor path given\n"
+	if !defined($fh) and !defined($path);
+
+    if (defined($path)) {
+	open($fh, '<', $path)
+	    or die "open stream path '$path' for reading failed: $!\n";
+    }
+
+    local $/;
+    my $data = <$fh>;
+
+    if (defined($encoding)) {
+	die "unknown 'content-encoding' $encoding\n" if $encoding ne 'gzip';
+	my $out;
+	gunzip(\$data => \$out);
+	$data = $out;
+    }
+
+    if (defined($type) && not $type =~ qw!^text/plain!) {
+	die "unknown 'content-type' $type\n" if not $type =~ qw!^application/json!;
+	$data = decode_json($data)->{data};
+    }
+
+    return $data;
+};
+
 sub call_api_method {
     my ($cmd, $param) = @_;

@@ -310,6 +342,9 @@ sub call_api_method {
 	}

 	$data = $handler->handle($info, $param);
+
+	$data = &$handle_streamed_response($data->{download})
+	    if ref($data) eq 'HASH' && ref($data->{download}) eq 'HASH';
     }

     return if $opt_nooutput || $stdopts->{quiet};
--
2.39.2

Re: [pve-devel] [PATCH manager] pvesh: decode streamed responses

[Wolfgang Bumiller]

looks mostly fine, I'd like some minor changes:

On Thu, Mar 30, 2023 at 11:25:20AM +0200, Christoph Heiss wrote:
> This allows to use `pvesh` on endpoints like /nodes/{node}/journal,
> which return streamed (and possibly gzip'd) responses.
> 
> Currently, e.g. `pvesh get /nodes/localhost/journal --lastentries 10`
> fails with:
> 
>   gzip: stdout: Broken pipe
>   got hash object, but result schema specified array!
> 
> Using e.g. `--output-format yaml` resulted in:
> 
>   ---
>   download:
>     content-encoding: gzip
>     content-type: application/json
>     fh: &1 !!perl/ref
>       =: *1
>     stream: 1
> 
>   gzip: stdout: Broken pipe
>   Failed to write
> 
> This is due the API call returning a "download" object (as seen above),
> which contains (among some other things) a file handle to read the
> response from.
> 
> With this patch, the response from such endpoints is now correctly read
> and displayed. Only handles combinations of `Content-Encoding` == 'gzip'
> and either 'text/plain' or 'application/json' for `Content-Type`.
> 
> This tries to mimic the behavior of the API server implementation when
> encountering `download` objects.
> 
> Tested this with all four output formats 'text', 'json', 'json-pretty'
> and 'yaml', as well as "cross-node" in a local test cluster.
> 
> Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
> ---
> As far as I could see (aka. grep for it), the only two endpoints which
> implement this are /nodes/{node}/journal and
> /nodes/{node}/tasks/{upid}/log, latter one only with `--download 1`
> set.
> 
>  PVE/CLI/pvesh.pm | 35 +++++++++++++++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/PVE/CLI/pvesh.pm b/PVE/CLI/pvesh.pm
> index 9acf292a..764d47a2 100755
> --- a/PVE/CLI/pvesh.pm
> +++ b/PVE/CLI/pvesh.pm
> @@ -15,6 +15,7 @@ use PVE::CLIHandler;
>  use PVE::API2Tools;
>  use PVE::API2;
>  use JSON;
> +use IO::Uncompress::Gunzip qw(gunzip);
> 
>  use base qw(PVE::CLIHandler);
> 
> @@ -281,6 +282,37 @@ my $cond_add_standard_output_properties = sub {
>      return PVE::RESTHandler::add_standard_output_properties($props, $keys);
>  };
> 
> +my $handle_streamed_response = sub {
> +    my ($download) = @_;
> +    my ($fh, $path, $encoding, $type) =
> +	$download->@{'fh', 'path', 'content-encoding', 'content-type'};
> +
> +    die "{download} returned but neither fh nor path given\n"
> +	if !defined($fh) and !defined($path);

^ style nit: use && here please

> +
> +    if (defined($path)) {
> +	open($fh, '<', $path)
> +	    or die "open stream path '$path' for reading failed: $!\n";
> +    }
> +
> +    local $/;
> +    my $data = <$fh>;
> +
> +    if (defined($encoding)) {
> +	die "unknown 'content-encoding' $encoding\n" if $encoding ne 'gzip';
> +	my $out;
> +	gunzip(\$data => \$out);
> +	$data = $out;
> +    }
> +
> +    if (defined($type) && not $type =~ qw!^text/plain!) {

style: `$type !~ …` instead of 'not $type =~ …'

> +	die "unknown 'content-type' $type\n" if not $type =~ qw!^application/json!;

Would be nice to move the $type check above the part doing the gunzip()
to avoid unnecessary work.

> +	$data = decode_json($data)->{data};
> +    }
> +
> +    return $data;
> +};
> +
>  sub call_api_method {
>      my ($cmd, $param) = @_;
> 
> @@ -310,6 +342,9 @@ sub call_api_method {
>  	}
> 
>  	$data = $handler->handle($info, $param);
> +
> +	$data = &$handle_streamed_response($data->{download})
> +	    if ref($data) eq 'HASH' && ref($data->{download}) eq 'HASH';
>      }
> 
>      return if $opt_nooutput || $stdopts->{quiet};
> --
> 2.39.2

Re: [pve-devel] [PATCH manager] pvesh: decode streamed responses

[Christoph Heiss]

On Wed, Jun 07, 2023 at 08:54:44AM +0200, Wolfgang Bumiller wrote:
> looks mostly fine, I'd like some minor changes:
Thanks for the review!

>
> On Thu, Mar 30, 2023 at 11:25:20AM +0200, Christoph Heiss wrote:
> > [..]
> >
> > +my $handle_streamed_response = sub {
> > +    my ($download) = @_;
> > +    my ($fh, $path, $encoding, $type) =
> > +	$download->@{'fh', 'path', 'content-encoding', 'content-type'};
> > +
> > +    die "{download} returned but neither fh nor path given\n"
> > +	if !defined($fh) and !defined($path);
>
> ^ style nit: use && here please
Ack.

>
> > +
> > +    if (defined($path)) {
> > +	open($fh, '<', $path)
> > +	    or die "open stream path '$path' for reading failed: $!\n";
> > +    }
> > +
> > +    local $/;
> > +    my $data = <$fh>;
> > +
> > +    if (defined($encoding)) {
> > +	die "unknown 'content-encoding' $encoding\n" if $encoding ne 'gzip';
> > +	my $out;
> > +	gunzip(\$data => \$out);
> > +	$data = $out;
> > +    }
> > +
> > +    if (defined($type) && not $type =~ qw!^text/plain!) {
>
> style: `$type !~ …` instead of 'not $type =~ …'
Did not know !~ existed as operator as well :^)

>
> > +	die "unknown 'content-type' $type\n" if not $type =~ qw!^application/json!;
>
> Would be nice to move the $type check above the part doing the gunzip()
> to avoid unnecessary work.
I'll restructure that, thanks.

>
> > [..]