Let's just go back to the start on this one as light has dawned on
marblehead and it's now clear what the technicality I was missing on the
reinterpretation of the API docs.

On 07/04/2018 05:23 AM, Michal Privoznik wrote:
> The documentation to virCommandWait() function states that if
> @exitstatus is NULL and command finished with error -1 is
> returned. In other words, if @dryRunCallback is set and returns
> an error (by setting its @status argument to a nonzero value) we
> must propagate this error properly honouring the documentation
> (and also regular run).



The documentation to virCommandWait() functions states "If @exitstatus
is NULL, then the child must exit with status 0 for this to succeed."

Thus if a dryRunCallback environment doesn't pass @exitstatus, then when
@dryRunStatus is not zero we must return -1.

...

So the technicality is that dryRunCallback is always set - whether it's
set to 0 in virCommandRunAsync or (inexplicably at this point) to some
other value in some as yet to be created mocked/fictitious environment.

My first gut instinct on this was why not just return dryRunStatus, but
that conflicts with the exitstatus rules and well I just couldn't get
past that.


> 
> Signed-off-by: Michal Privoznik <mpriv...@redhat.com>
> ---
>  src/util/vircommand.c | 2 ++
>  1 file changed, 2 insertions(+)
> 

Reviewed-by: John Ferlan <jfer...@redhat.com>

John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to