----- Original Message -----
From: "Yaniv Bronheim" <ybronhei(a)redhat.com>
To: "Tomáš Golembiovský" <tgolembi(a)redhat.com>
Cc: "devel" <devel(a)ovirt.org>
Sent: Monday, July 11, 2016 6:28:10 PM
Subject: Re: [ovirt-devel] execCmd() and storing stdout and stderr in log file
On Mon, Jul 11, 2016 at 12:53 PM, Tomáš Golembiovský < tgolembi(a)redhat.com >
wrote:
On Wed, 6 Jul 2016 18:37:54 +0300
Yaniv Bronheim < ybronhei(a)redhat.com > wrote:
> On Wed, Jul 6, 2016 at 5:07 PM, Tomáš Golembiovský < tgolembi(a)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.
In vdsm we currently use cpopen to start external process - as
multiprocess.popen in py2 is buggy. using execCmd doesn't provide stderr and
stdout parameters to modify. but you can use CPopen directly and override
stderr.
Over py3 we import the standard multiprocess.Popen. basically if its actually
useful you can add those parameters to execCmd
Good news about cpopen!
Is it a good idea to add even more parameters to execCmd? Let's discuss this.
another approach I could think of is
https://gerrit.ovirt.org/#/c/60660/
I'm not that proud of 60660 either, this is why it is a draft :\
So I've been in touch with Tomas, and he kindly tried to rebase his code
on top of my 60660, but looks like he was biten by issues fixed in
https://gerrit.ovirt.org/#/c/59181/
https://gerrit.ovirt.org/#/c/59095/
I think leveraging cpopen is a good way, it is simple enough and it doesn't
hurt our plans to eventually move to subprocess.
Thoughts welcome
Thanks and bests,
--
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani