[ovirt-devel] execCmd() and storing stdout and stderr in log file

[Nir Soffer]

On Mon, Jul 11, 2016 at 12:53 PM, Tomáš Golembiovský
<tgolembi at redhat.com> wrote:
> On Wed, 6 Jul 2016 18:37:54 +0300
> Yaniv Bronheim <ybronhei at redhat.com> wrote:
>
>> On Wed, Jul 6, 2016 at 5:07 PM, Tomáš Golembiovský <tgolembi at redhat.com>
>> wrote:
>>
>> >
>> > Merging stdout and stderr to one can POpen do for us, I belive. Any
>> > logging can indeed be done as a wrapper around execCmd.
>>
>> saving stdout and err to log while the process is running is useful only
>> for your purpose currently. using asyncproc as you do now in v2v allows you
>> to to run a process and monitor it.. can you use overriding of aysncProc
>> wrapper for your needs instead of changing cpopen or execcmd code?
>
> I am not talking about CPOpen. I meant that when calling
> `subprocess.Popen`, you can pass it `stderr=subprocess.STDOUT` argument
> and it will handle the FD redirection (stream merging). To me it seems
> like a proper way of doing this.

This should work with execCmd, since the special subprocess.STDOUT
parameter is handled in subprocess.Popen, and cpopen.CPopen inherit
this code. However this is not tested with cpopen, so it may be broken.

But merging stdout and stderr is likely to break v2v output parser, and vdsm
log is not the place for virt-v2v debug logs.

I understand that the issue is keeping virt-v2v debug logs (using --verbose?),
and the logs are spread in stdout and stderr. Did you discuss this issue
with Richard?

I would use tee to write stdout and stderr to an import log file, without
changing the code checking import progress.

Maybe virt-v2v can add a --logfile option appending to given log file?

Richard, what do you think?

>
>
>> > > [...]
>> > >
>> > > btw, after examine the area again, isn't watchCmd func is what you
>> > >  describe? we just need to replace the asyncProc usages there with
>> > > something that doesn't use StringIO as we do to support py3
>> >
>> > I'm not sure how watchCmd can help with this. Isn't it just a wrapper to
>> > get asynchrounous process with a stop condition?
>> >
>>
>> it is. thought you need something similar and afterwards log the outputs
>
> I can run async process with `execCmd` directly and I don't need any
> stop condition. Am I missing something that `watchCmd` provides?
>
> --
> Tomáš Golembiovský <tgolembi at redhat.com>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel