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

[Yaniv Bronheim]

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

On Fri, Jul 1, 2016 at 5:43 PM, Tomáš Golembiovský <tgolembi at redhat.com>
wrote:

> Hi,
>
> I had a need recently to run a command with execCmd() and store it's
> output and error to a log file, while still receiving it in the calling
> code. Redirecting the error to output stream to have all in one stream
> is also useful feature.
>
> All this can be done in the calling code:
>
> a)  On the shell level, by modyfing the command. This can be
> intentionally dangerous because things like quoting of arguments has to
> be considered and also could cause problems when wrappers (sudo, nice,
> ...) are used.
>
> b)  By handling the writing to files in a code. This would add
> unnecessary code duplication in a long run. (I don't think I'm the only
> one who can see a potential in this.) Also for asynchronous process
> runs, when storing both stderr & stdout in one file, it requires polling
> and some stream magic. It would be better to have this done right and
> only once so it can be properly tested.
>
> That's why I think having it present in execCmd() ready for everyone's
> use is the best solution. Unfortunately it seems that the code is a)
> essential on many places in vdsm and b) not properly covered by tests.
> Which makes it hard to touch. Also apparently some refactoring is either
> planned or already underway.
>
> What is the situation about refactoring that code area? Anyone working
> on it? Do we have an estimation of time-frame for it?
>
> Any suggestions/ideas?
>
>
>     Tomas
>
> --
> Tomáš Golembiovský <tgolembi at redhat.com>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel




-- 
*Yaniv Bronhaim.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160705/9e7944b9/attachment-0001.html>