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@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@redhat.com>
_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

--

Yaniv Bronhaim.