* [pve-devel] [PATCH manager v2] pvesh: decode streamed responses
@ 2023-06-07 14:15 Christoph Heiss
2023-10-19 7:28 ` Christoph Heiss
2023-10-21 14:36 ` [pve-devel] applied: " Thomas Lamprecht
0 siblings, 2 replies; 3+ messages in thread
From: Christoph Heiss @ 2023-06-07 14:15 UTC (permalink / raw)
To: pve-devel
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>
---
Changes v1 -> v2:
* Fix some style nits
* Move content-{encoding,type} checks before actual decoding
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 | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/PVE/CLI/pvesh.pm b/PVE/CLI/pvesh.pm
index 9acf292a..c0c8187b 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,41 @@ 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) && !defined($path);
+
+ die "unknown 'content-encoding' $encoding\n"
+ if defined($encoding) && $encoding ne 'gzip';
+
+ die "unknown 'content-type' $type\n"
+ if defined($type) && $type !~ qw!^(text/plain)|(application/json)$!;
+
+ if (defined($path)) {
+ open($fh, '<', $path)
+ or die "open stream path '$path' for reading failed: $!\n";
+ }
+
+ local $/;
+ my $data = <$fh>;
+
+ if (defined($encoding)) {
+ my $out;
+ gunzip(\$data => \$out);
+ $data = $out;
+ }
+
+ if (defined($type) && $type eq 'application/json') {
+ $data = decode_json($data)->{data};
+ }
+
+ return $data;
+};
+
sub call_api_method {
my ($cmd, $param) = @_;
@@ -310,6 +346,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.40.1
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [pve-devel] [PATCH manager v2] pvesh: decode streamed responses
2023-06-07 14:15 [pve-devel] [PATCH manager v2] pvesh: decode streamed responses Christoph Heiss
@ 2023-10-19 7:28 ` Christoph Heiss
2023-10-21 14:36 ` [pve-devel] applied: " Thomas Lamprecht
1 sibling, 0 replies; 3+ messages in thread
From: Christoph Heiss @ 2023-10-19 7:28 UTC (permalink / raw)
Cc: Proxmox VE development discussion
Ping, still applies.
On Wed, Jun 07, 2023 at 04:15:11PM +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>
> ---
> Changes v1 -> v2:
> * Fix some style nits
> * Move content-{encoding,type} checks before actual decoding
>
> 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 | 39 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/PVE/CLI/pvesh.pm b/PVE/CLI/pvesh.pm
> index 9acf292a..c0c8187b 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,41 @@ 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) && !defined($path);
> +
> + die "unknown 'content-encoding' $encoding\n"
> + if defined($encoding) && $encoding ne 'gzip';
> +
> + die "unknown 'content-type' $type\n"
> + if defined($type) && $type !~ qw!^(text/plain)|(application/json)$!;
> +
> + if (defined($path)) {
> + open($fh, '<', $path)
> + or die "open stream path '$path' for reading failed: $!\n";
> + }
> +
> + local $/;
> + my $data = <$fh>;
> +
> + if (defined($encoding)) {
> + my $out;
> + gunzip(\$data => \$out);
> + $data = $out;
> + }
> +
> + if (defined($type) && $type eq 'application/json') {
> + $data = decode_json($data)->{data};
> + }
> +
> + return $data;
> +};
> +
> sub call_api_method {
> my ($cmd, $param) = @_;
>
> @@ -310,6 +346,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.40.1
>
>
>
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* [pve-devel] applied: [PATCH manager v2] pvesh: decode streamed responses
2023-06-07 14:15 [pve-devel] [PATCH manager v2] pvesh: decode streamed responses Christoph Heiss
2023-10-19 7:28 ` Christoph Heiss
@ 2023-10-21 14:36 ` Thomas Lamprecht
1 sibling, 0 replies; 3+ messages in thread
From: Thomas Lamprecht @ 2023-10-21 14:36 UTC (permalink / raw)
To: Proxmox VE development discussion, Christoph Heiss
Am 07/06/2023 um 16:15 schrieb 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>
> ---
> Changes v1 -> v2:
> * Fix some style nits
> * Move content-{encoding,type} checks before actual decoding
>
> 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 | 39 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
>
applied, thanks!
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-10-21 14:36 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-07 14:15 [pve-devel] [PATCH manager v2] pvesh: decode streamed responses Christoph Heiss
2023-10-19 7:28 ` Christoph Heiss
2023-10-21 14:36 ` [pve-devel] applied: " Thomas Lamprecht
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox