Red Hat Bugzilla – Bug 1459075
[RFE][CodeChange] Replace python-cpopen usage with python-subprocess32
Last modified: 2017-12-20 06:16:08 EST
Description of problem:
python2's subprocess is buggy, which prompted us to replace it with python-cpopen. Since then, python-subprocess32 has provided a better solution: it backports python3's subprocess to python2.
Let us dump our own implementation, and replace it with a python3-compatible solution that is developed upstream.
The package is built in CentOS so importing its RPM to RHV should be relatively easy.
I started to check what is still missing for such https://gerrit.ovirt.org/78659 replacement. We still have in both imageSharing.py qemuimg.py a "deathSignal" usage that we need to eliminate. Except that, I will send PIPE as default stdout and stdin when we call execCmd, and the rest is fine.. I'll continue verification after imagesharing.py and qemuimg.py will be fixed. I'm not sure what is the reason for still counting on signal when we run with systemctl.. I though we're already fine there
We will remove the deathSignal from the few places using it.
https://gerrit.ovirt.org/75009 is removing one instance.
Moving the intention of this bug to be about the vdsm usages in python-copen - As we discussed few weeks ago, seems like all left locations that need modification are storage areas and requires storage team followup.
The build in centos is ready (see Bug 1470218). If something still missing let me know
What is the right target for this?
(In reply to Yaniv Lavi from comment #6)
> What is the right target for this?
The work was completed in vdsm few weeks ago, I think this can be in 4.2.0 and
mark as modified/onqa.
This is included in current master, so can be moved to ON_QA when qa have time to test it.
There is no behavior change, running automation is enough to verify the changes.
There was a similar effort in ioprocess - version 1.0 (working on the release)
also uses now suprocess32:
(In reply to Nir Soffer from comment #8)
> This is included in current master, so can be moved to ON_QA when qa have
> time to test it.
> There is no behavior change, running automation is enough to verify the
Based on this comment and since we haven't seen any unusual behavior in out automation tests, moving to verified.
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.
Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.
If the solution does not work for you, please open a new bug report.