
On Thu, 14 Jul 2016 15:07:29 +0300 Nir Soffer <nsoffer@redhat.com> wrote:
On Mon, Jul 11, 2016 at 12:53 PM, Tomáš Golembiovský <tgolembi@redhat.com> wrote:
On Wed, 6 Jul 2016 18:37:54 +0300 Yaniv Bronheim <ybronhei@redhat.com> wrote:
On Wed, Jul 6, 2016 at 5:07 PM, Tomáš Golembiovský <tgolembi@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.
This is something that we can deal with.
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?
Not yet.
I would use tee to write stdout and stderr to an import log file, without changing the code checking import progress.
This is something I have tried as first, as you can see here: https://gerrit.ovirt.org/#/c/59834/4/lib/vdsm/v2v.py@404 The problem with this approach is that we don't get proper exit code from virt-v2v because of the pipe. Fixing this in POSIX shell is not trivial and would lead to more complex shell code here. (Would be fairly easy to fix if we could resort to using bash here.)
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@redhat.com> _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Tomáš Golembiovský <tgolembi@redhat.com>