[pve-devel] [PATCH manager 1/1] api: journal: stream the journal data to the client

[Stoiko Ivanov]

Huge thanks for addressing this so quickly and elegantly!

One question/nit:

On Wed, 24 Nov 2021 15:47:48 +0100
Dominik Csapak <d.csapak at proxmox.com> wrote:

> instead of accumulating the whole output of 'mini-journalreader' in
> the api call (this can be quite big), use the download mechanic of the
> http-server to stream the output to the client.
> 
> we lose some error handling possibilities, but we do not have
> to allocate anything here, and since perl does not free memory after
> allocating[0] this is our desired behaviour.
> 
> to keep api compatiblitiy, we need to give the journalreader the '-j'
> flag to let it output json.
> 
> also tell the http server that the encoding is gzip and pipe
> the output through it.
> 
> 0: https://perldoc.perl.org/perlfaq3#How-can-I-free-an-array-or-hash-so-my-program-shrinks?
> 
> Signed-off-by: Dominik Csapak <d.csapak at proxmox.com>
> ---
>  PVE/API2/Nodes.pm | 22 ++++++++++++++--------
>  1 file changed, 14 insertions(+), 8 deletions(-)
> 
> diff --git a/PVE/API2/Nodes.pm b/PVE/API2/Nodes.pm
> index 565cbccc..d57a1937 100644
> --- a/PVE/API2/Nodes.pm
> +++ b/PVE/API2/Nodes.pm
> @@ -819,19 +819,25 @@ __PACKAGE__->register_method({
>  	my $rpcenv = PVE::RPCEnvironment::get();
>  	my $user = $rpcenv->get_user();
>  
> -	my $cmd = ["/usr/bin/mini-journalreader"];
> +	my $cmd = ["/usr/bin/mini-journalreader", "-j"];
>  	push @$cmd, '-n', $param->{lastentries} if $param->{lastentries};
>  	push @$cmd, '-b', $param->{since} if $param->{since};
>  	push @$cmd, '-e', $param->{until} if $param->{until};
> -	push @$cmd, '-f', $param->{startcursor} if $param->{startcursor};
> -	push @$cmd, '-t', $param->{endcursor} if $param->{endcursor};
> +	push @$cmd, '-f', PVE::Tools::shellquote($param->{startcursor}) if $param->{startcursor};
> +	push @$cmd, '-t', PVE::Tools::shellquote($param->{endcursor}) if $param->{endcursor};
> +	push @$cmd, ' | gzip ';
Not sure which would be more efficient - but the http-server does support
gzipping the result from the API
might it make sense to let the worker do the gzip-encoding vs. forking
gzip here?

>  
> -	my $lines = [];
> -	my $parser = sub { push @$lines, shift };
> +	open(my $fh, "-|", join(' ', @$cmd))
> +	    or die "could not start mini-journalreader";
>  
> -	PVE::Tools::run_command($cmd, outfunc => $parser);
> -
> -	return $lines;
> +	return {
> +	    download => {
> +		fh => $fh,
> +		stream => 1,
> +		'content-type' => 'application/json',
> +		'content-encoding' => 'gzip',
if yes - I think it would only need to signal it here (maybe compress => 1)
and set the '$nocomp' parameter to the response sub in AnyEvent.pm based
on that (this last part without trying it out)

> +	    },
> +	},
>      }});
>  
>  my $sslcert;