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

Tomáš Golembiovský tgolembi at redhat.com
Wed Jul 6 14:07:09 UTC 2016


On Tue, 5 Jul 2016 11:18:58 +0300
Yaniv Bronheim <ybronhei at redhat.com> wrote:

> On Tue, Jul 5, 2016 at 10:44 AM, Yaniv Bronheim <ybronhei at redhat.com> wrote:
> 
> > Hi
> > I do work to remove the cpopen usages from execCmd. Using std popen over
> > py3 and subprocess32 over py2 which both implements the same api. The only
> > gap is the output object for async calls that we need to align with the
> > standard implementation and modify our current usages. I don't think that
> > adding more non-standard logics to execCmd is a good idea. we should fit
> > the standard usage in this function or override it separately with specific
> > implementation in commands.py. You may propose such patch

Sure, that makes sense. Are there any existing drafts/patches I could
look at or help with?

Merging stdout and stderr to one can POpen do for us, I belive. Any
logging can indeed be done as a wrapper around execCmd.


> [...]
>
> 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?

Could you elaborate on why we want to get rid of StringIO in AsyncProc?
If I understand it right, it's purpose is to make sure the executed
program doesn't stall on full pipe if VDSM isn't fast enough in
processing the output. Or am I missing something? But it could again be
implemented as a wrapper around execCmd and not in it. Is that what you
mean?


-- 
Tomáš Golembiovský <tgolembi at redhat.com>



More information about the Devel mailing list