Il 29/01/2014 09:21, Sven Kieske ha scritto:
Hi,
I wanted to try it the other way around, installing vdsm-python-cpopen and check if it runs without python-cpopen .
But that leads me to a question:
Is there any difference between these packages beside their different name?
If yes, what is the difference and which package should be installed? I no, why is there a packet vdsm-python-cpopen ?
CCing VDSM
Thank you!
Am 28.01.2014 20:14, schrieb Trey Dockendorf:
I found manually installing python-cpopen before adding a node in the engine is a viable workaround. This was on EL6.5
- Trey
Hi,
any news regarding my questions?
Am 29.01.2014 09:23, schrieb Sandro Bonazzola:
Il 29/01/2014 09:21, Sven Kieske ha scritto:
Hi,
I wanted to try it the other way around, installing vdsm-python-cpopen and check if it runs without python-cpopen .
But that leads me to a question:
Is there any difference between these packages beside their different name?
If yes, what is the difference and which package should be installed? I no, why is there a packet vdsm-python-cpopen ?
CCing VDSM
Am 28.01.2014 20:14, schrieb Trey Dockendorf:
I found manually installing python-cpopen before adding a node in the engine is a viable workaround. This was on EL6.5
On Thu, Jan 30, 2014 at 08:52:36AM +0000, Sven Kieske wrote:
Hi,
any news regarding my questions?
Am 29.01.2014 09:23, schrieb Sandro Bonazzola:
Il 29/01/2014 09:21, Sven Kieske ha scritto:
Hi,
I wanted to try it the other way around, installing vdsm-python-cpopen and check if it runs without python-cpopen .
But that leads me to a question:
Is there any difference between these packages beside their different name?
If yes, what is the difference and which package should be installed? I no, why is there a packet vdsm-python-cpopen ?
CCing VDSM
python-cpopen includes some improvements and bug fixes, that are going to be needed in ovirt-3.4. vdsm-python-cpopen is shipped by ovirt-3.3.
python-cpopen wast intended to deprecate and replace vdsm-python-cpopen, but we have had way too many issues trying to do that properly in rpm/yum. Most of the bugs are ours, at least one is yum's.
At the moment, the existence of python-cpopen in Fedora confuses `yum install vdsm`.
To avoid this unfortunate delay, we can either include python-cpopen in ovirt-stable or exclude vdsm-python-cpopen from there. Both options are unfavorable, but so is continuing to wait.
Regards, Dan.
Il 30/01/2014 10:20, Dan Kenigsberg ha scritto:
On Thu, Jan 30, 2014 at 08:52:36AM +0000, Sven Kieske wrote:
Hi,
any news regarding my questions?
Am 29.01.2014 09:23, schrieb Sandro Bonazzola:
Il 29/01/2014 09:21, Sven Kieske ha scritto:
Hi,
I wanted to try it the other way around, installing vdsm-python-cpopen and check if it runs without python-cpopen .
But that leads me to a question:
Is there any difference between these packages beside their different name?
If yes, what is the difference and which package should be installed? I no, why is there a packet vdsm-python-cpopen ?
CCing VDSM
python-cpopen includes some improvements and bug fixes, that are going to be needed in ovirt-3.4. vdsm-python-cpopen is shipped by ovirt-3.3.
python-cpopen wast intended to deprecate and replace vdsm-python-cpopen, but we have had way too many issues trying to do that properly in rpm/yum. Most of the bugs are ours, at least one is yum's.
At the moment, the existence of python-cpopen in Fedora confuses `yum install vdsm`.
To avoid this unfortunate delay, we can either include python-cpopen in ovirt-stable or exclude vdsm-python-cpopen from there. Both options are unfavorable, but so is continuing to wait.
If it's enough just to add python-cpopen to ovirt-stable, I'm fine with that. I just need the link to the build to be included there.
Regards, Dan.
On Thu, Jan 30, 2014 at 10:27:34AM +0100, Sandro Bonazzola wrote:
Il 30/01/2014 10:20, Dan Kenigsberg ha scritto:
On Thu, Jan 30, 2014 at 08:52:36AM +0000, Sven Kieske wrote:
Hi,
any news regarding my questions?
Am 29.01.2014 09:23, schrieb Sandro Bonazzola:
Il 29/01/2014 09:21, Sven Kieske ha scritto:
Hi,
I wanted to try it the other way around, installing vdsm-python-cpopen and check if it runs without python-cpopen .
But that leads me to a question:
Is there any difference between these packages beside their different name?
If yes, what is the difference and which package should be installed? I no, why is there a packet vdsm-python-cpopen ?
CCing VDSM
python-cpopen includes some improvements and bug fixes, that are going to be needed in ovirt-3.4. vdsm-python-cpopen is shipped by ovirt-3.3.
python-cpopen wast intended to deprecate and replace vdsm-python-cpopen, but we have had way too many issues trying to do that properly in rpm/yum. Most of the bugs are ours, at least one is yum's.
At the moment, the existence of python-cpopen in Fedora confuses `yum install vdsm`.
To avoid this unfortunate delay, we can either include python-cpopen in ovirt-stable or exclude vdsm-python-cpopen from there. Both options are unfavorable, but so is continuing to wait.
If it's enough just to add python-cpopen to ovirt-stable, I'm fine with that. I just need the link to the build to be included there.
Yaniv, have you tried if shipping python-cpopen hides this issue?
http://kojipkgs.fedoraproject.org//packages/python-cpopen/1.3/1.fc20/x86_64/... http://kojipkgs.fedoraproject.org//packages/python-cpopen/1.3/1.fc19/x86_64/... http://kojipkgs.fedoraproject.org//packages/python-cpopen/1.3/1.el6/ppc64/py...
Dropping vdsm-python-cpopen from a stable version seems impolite, but should work, too.
Hey,
we found this yum bug and still struggling with more issuing according to the relation between those packages
if we drop vdsm-python-cpopen the requirement in vdsm takes python-cpopen instead. in python-cpopen we have the same code base and it provides all vdsm-ptyhon-cpopen provides, so shouldn't be any issues with dropping it from the repository
is it possible to ship 3.3.3 release that way ? we don't need to change the requirement in the code, if python-cpopen 1.3-1 is part of the release, it will be taken by vdsm spec (tried with vdsm 4.13.3-2 with the available cpopen 1.3-1)
Sven, for your question, install python-cpopen 1.3-1 for both 3.3 and 3.4 releases that you use, and the upgrade\downgrade should not raise any dependencies issues afaic
Yaniv Bronhaim.
----- Original Message -----
From: "Dan Kenigsberg" danken@redhat.com To: "Sandro Bonazzola" sbonazzo@redhat.com, ybronhei@redhat.com Cc: "Sven Kieske" S.Kieske@mittwald.de, "Trey Dockendorf" treydock@gmail.com, "users" users@ovirt.org, "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Thursday, January 30, 2014 4:02:13 PM Subject: Re: [Users] ovirt-3.3.3 release postponed due to blockers
On Thu, Jan 30, 2014 at 10:27:34AM +0100, Sandro Bonazzola wrote:
Il 30/01/2014 10:20, Dan Kenigsberg ha scritto:
On Thu, Jan 30, 2014 at 08:52:36AM +0000, Sven Kieske wrote:
Hi,
any news regarding my questions?
Am 29.01.2014 09:23, schrieb Sandro Bonazzola:
Il 29/01/2014 09:21, Sven Kieske ha scritto:
Hi,
I wanted to try it the other way around, installing vdsm-python-cpopen and check if it runs without python-cpopen .
But that leads me to a question:
Is there any difference between these packages beside their different name?
If yes, what is the difference and which package should be installed? I no, why is there a packet vdsm-python-cpopen ?
CCing VDSM
python-cpopen includes some improvements and bug fixes, that are going to be needed in ovirt-3.4. vdsm-python-cpopen is shipped by ovirt-3.3.
python-cpopen wast intended to deprecate and replace vdsm-python-cpopen, but we have had way too many issues trying to do that properly in rpm/yum. Most of the bugs are ours, at least one is yum's.
At the moment, the existence of python-cpopen in Fedora confuses `yum install vdsm`.
To avoid this unfortunate delay, we can either include python-cpopen in ovirt-stable or exclude vdsm-python-cpopen from there. Both options are unfavorable, but so is continuing to wait.
If it's enough just to add python-cpopen to ovirt-stable, I'm fine with that. I just need the link to the build to be included there.
Yaniv, have you tried if shipping python-cpopen hides this issue?
http://kojipkgs.fedoraproject.org//packages/python-cpopen/1.3/1.fc20/x86_64/... http://kojipkgs.fedoraproject.org//packages/python-cpopen/1.3/1.fc19/x86_64/... http://kojipkgs.fedoraproject.org//packages/python-cpopen/1.3/1.el6/ppc64/py...
Dropping vdsm-python-cpopen from a stable version seems impolite, but should work, too.
Il 30/01/2014 16:13, Yaniv Bronheim ha scritto:
Hey,
we found this yum bug and still struggling with more issuing according to the relation between those packages
if we drop vdsm-python-cpopen the requirement in vdsm takes python-cpopen instead. in python-cpopen we have the same code base and it provides all vdsm-ptyhon-cpopen provides, so shouldn't be any issues with dropping it from the repository
is it possible to ship 3.3.3 release that way ? we don't need to change the requirement in the code, if python-cpopen 1.3-1 is part of the release, it will be taken by vdsm spec (tried with vdsm 4.13.3-2 with the available cpopen 1.3-1)
I can't release 3.3.3 that way. We're keeping rolling releases on stable repository so if I don't provide 4.13.3-2, previous one will still be available.
Sven, for your question, install python-cpopen 1.3-1 for both 3.3 and 3.4 releases that you use, and the upgrade\downgrade should not raise any dependencies issues afaic
Yaniv Bronhaim.
----- Original Message -----
From: "Dan Kenigsberg" danken@redhat.com To: "Sandro Bonazzola" sbonazzo@redhat.com, ybronhei@redhat.com Cc: "Sven Kieske" S.Kieske@mittwald.de, "Trey Dockendorf" treydock@gmail.com, "users" users@ovirt.org, "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Thursday, January 30, 2014 4:02:13 PM Subject: Re: [Users] ovirt-3.3.3 release postponed due to blockers
On Thu, Jan 30, 2014 at 10:27:34AM +0100, Sandro Bonazzola wrote:
Il 30/01/2014 10:20, Dan Kenigsberg ha scritto:
On Thu, Jan 30, 2014 at 08:52:36AM +0000, Sven Kieske wrote:
Hi,
any news regarding my questions?
Am 29.01.2014 09:23, schrieb Sandro Bonazzola:
Il 29/01/2014 09:21, Sven Kieske ha scritto: > Hi, > > I wanted to try it the other way around, installing vdsm-python-cpopen > and check if it runs without python-cpopen . > > But that leads me to a question: > > Is there any difference between these packages beside their different > name? > > If yes, what is the difference and which package should be installed? > I no, why is there a packet vdsm-python-cpopen ?
CCing VDSM
python-cpopen includes some improvements and bug fixes, that are going to be needed in ovirt-3.4. vdsm-python-cpopen is shipped by ovirt-3.3.
python-cpopen wast intended to deprecate and replace vdsm-python-cpopen, but we have had way too many issues trying to do that properly in rpm/yum. Most of the bugs are ours, at least one is yum's.
At the moment, the existence of python-cpopen in Fedora confuses `yum install vdsm`.
To avoid this unfortunate delay, we can either include python-cpopen in ovirt-stable or exclude vdsm-python-cpopen from there. Both options are unfavorable, but so is continuing to wait.
If it's enough just to add python-cpopen to ovirt-stable, I'm fine with that. I just need the link to the build to be included there.
Yaniv, have you tried if shipping python-cpopen hides this issue?
http://kojipkgs.fedoraproject.org//packages/python-cpopen/1.3/1.fc20/x86_64/... http://kojipkgs.fedoraproject.org//packages/python-cpopen/1.3/1.fc19/x86_64/... http://kojipkgs.fedoraproject.org//packages/python-cpopen/1.3/1.el6/ppc64/py...
Dropping vdsm-python-cpopen from a stable version seems impolite, but should work, too.
Can we revert these packages to previous versions in the 3.3.2 stable repo so those of us who want/need to install new hosts in our clusters aren't dead in the water waiting for 3.3.3?
On Thu, 30 Jan 2014 16:26:51 +0100 Sandro wrote: SB> Il 30/01/2014 16:13, Yaniv Bronheim ha scritto: SB> > Hey, SB> > SB> > we found this yum bug and still struggling with more issuing SB> > according to the relation between those packages SB> > SB> > if we drop vdsm-python-cpopen the requirement in vdsm takes SB> > python-cpopen instead. in python-cpopen we have the same code base SB> > and it provides all vdsm-ptyhon-cpopen provides, so shouldn't be any SB> > issues with dropping it from the repository SB> > SB> > is it possible to ship 3.3.3 release that way ? we don't need to SB> > change the requirement in the code, if python-cpopen 1.3-1 is part of SB> > the release, it will be taken by vdsm spec (tried with vdsm 4.13.3-2 SB> > with the available cpopen 1.3-1) SB> > SB> SB> I can't release 3.3.3 that way. SB> We're keeping rolling releases on stable repository so if I don't SB> provide 4.13.3-2, previous one will still be available.
Robert
-- Senior Software Engineer @ Parsons
Il 30/01/2014 22:38, Robert Story ha scritto:
Can we revert these packages to previous versions in the 3.3.2 stable repo so those of us who want/need to install new hosts in our clusters aren't dead in the water waiting for 3.3.3?
Hi Robert, I think you can still install 3.3.2 on your clusters with the requirement of adding manually oython-cpopen before trying to install vdsm.
About 3.3.3, I think vdsm should really drop dependency on vdsm-python-cpopen: it's a package obsoleted by python-cpopen so there's no point in still requiring it especially if keeping that requirement still break dependency resolution.
On Thu, 30 Jan 2014 16:26:51 +0100 Sandro wrote: SB> Il 30/01/2014 16:13, Yaniv Bronheim ha scritto: SB> > Hey, SB> > SB> > we found this yum bug and still struggling with more issuing SB> > according to the relation between those packages SB> > SB> > if we drop vdsm-python-cpopen the requirement in vdsm takes SB> > python-cpopen instead. in python-cpopen we have the same code base SB> > and it provides all vdsm-ptyhon-cpopen provides, so shouldn't be any SB> > issues with dropping it from the repository SB> > SB> > is it possible to ship 3.3.3 release that way ? we don't need to SB> > change the requirement in the code, if python-cpopen 1.3-1 is part of SB> > the release, it will be taken by vdsm spec (tried with vdsm 4.13.3-2 SB> > with the available cpopen 1.3-1) SB> > SB> SB> I can't release 3.3.3 that way. SB> We're keeping rolling releases on stable repository so if I don't SB> provide 4.13.3-2, previous one will still be available.
Robert
-- Senior Software Engineer @ Parsons
On Fri, Jan 31, 2014 at 09:36:48AM +0100, Sandro Bonazzola wrote:
Il 30/01/2014 22:38, Robert Story ha scritto:
Can we revert these packages to previous versions in the 3.3.2 stable repo so those of us who want/need to install new hosts in our clusters aren't dead in the water waiting for 3.3.3?
Hi Robert, I think you can still install 3.3.2 on your clusters with the requirement of adding manually oython-cpopen before trying to install vdsm.
About 3.3.3, I think vdsm should really drop dependency on vdsm-python-cpopen: it's a package obsoleted by python-cpopen so there's no point in still requiring it especially if keeping that requirement still break dependency resolution.
I really wanted to avoid eliminating a subpackage during a micro release. That's impolite and surprising. But given the awkward yum bug, persistent dependency problems, and the current release delay, I give up.
Let's eliminate vdsm-python-cpopen from ovirt-3.3 branch, and require python-cpopen. Yaniv, Douglas: could you handle it?
Il 31/01/2014 11:17, Dan Kenigsberg ha scritto:
On Fri, Jan 31, 2014 at 09:36:48AM +0100, Sandro Bonazzola wrote:
Il 30/01/2014 22:38, Robert Story ha scritto:
Can we revert these packages to previous versions in the 3.3.2 stable repo so those of us who want/need to install new hosts in our clusters aren't dead in the water waiting for 3.3.3?
Hi Robert, I think you can still install 3.3.2 on your clusters with the requirement of adding manually oython-cpopen before trying to install vdsm.
About 3.3.3, I think vdsm should really drop dependency on vdsm-python-cpopen: it's a package obsoleted by python-cpopen so there's no point in still requiring it especially if keeping that requirement still break dependency resolution.
I really wanted to avoid eliminating a subpackage during a micro release. That's impolite and surprising.
I'm not telling you to not provide vdsm-python-cpopen while you build vdsm. I'm telling you to not require it. You can still build it and let it to be unused. Just treat vdsm-python-cpopen as something not provided anymore by the distro while python-cpopen is the new one replacing it.
But given the awkward yum bug, persistent dependency problems, and the current release delay, I give up.
Let's eliminate vdsm-python-cpopen from ovirt-3.3 branch, and require python-cpopen. Yaniv, Douglas: could you handle it?
On 01/31/2014 05:17 AM, Dan Kenigsberg wrote:
On Fri, Jan 31, 2014 at 09:36:48AM +0100, Sandro Bonazzola wrote:
Il 30/01/2014 22:38, Robert Story ha scritto:
Can we revert these packages to previous versions in the 3.3.2 stable repo so those of us who want/need to install new hosts in our clusters aren't dead in the water waiting for 3.3.3?
Hi Robert, I think you can still install 3.3.2 on your clusters with the requirement of adding manually oython-cpopen before trying to install vdsm.
About 3.3.3, I think vdsm should really drop dependency on vdsm-python-cpopen: it's a package obsoleted by python-cpopen so there's no point in still requiring it especially if keeping that requirement still break dependency resolution.
I really wanted to avoid eliminating a subpackage during a micro release. That's impolite and surprising. But given the awkward yum bug, persistent dependency problems, and the current release delay, I give up.
Let's eliminate vdsm-python-cpopen from ovirt-3.3 branch, and require python-cpopen. Yaniv, Douglas: could you handle it?
Sure. Done: http://gerrit.ovirt.org/#/c/23942/
On Fri, Jan 31, 2014 at 04:16:54PM -0500, Douglas Schilling Landgraf wrote:
On 01/31/2014 05:17 AM, Dan Kenigsberg wrote:
On Fri, Jan 31, 2014 at 09:36:48AM +0100, Sandro Bonazzola wrote:
Il 30/01/2014 22:38, Robert Story ha scritto:
Can we revert these packages to previous versions in the 3.3.2 stable repo so those of us who want/need to install new hosts in our clusters aren't dead in the water waiting for 3.3.3?
Hi Robert, I think you can still install 3.3.2 on your clusters with the requirement of adding manually oython-cpopen before trying to install vdsm.
About 3.3.3, I think vdsm should really drop dependency on vdsm-python-cpopen: it's a package obsoleted by python-cpopen so there's no point in still requiring it especially if keeping that requirement still break dependency resolution.
I really wanted to avoid eliminating a subpackage during a micro release. That's impolite and surprising. But given the awkward yum bug, persistent dependency problems, and the current release delay, I give up.
Let's eliminate vdsm-python-cpopen from ovirt-3.3 branch, and require python-cpopen. Yaniv, Douglas: could you handle it?
Sure. Done: http://gerrit.ovirt.org/#/c/23942/
Acked. Could you cherry-pick it into dist-git and rebuild the ovirt-3.3.3 candidate (and without other changes that can wait for ovirt-3.3.4).
Il 02/02/2014 00:05, Dan Kenigsberg ha scritto:
On Fri, Jan 31, 2014 at 04:16:54PM -0500, Douglas Schilling Landgraf wrote:
On 01/31/2014 05:17 AM, Dan Kenigsberg wrote:
On Fri, Jan 31, 2014 at 09:36:48AM +0100, Sandro Bonazzola wrote:
Il 30/01/2014 22:38, Robert Story ha scritto:
Can we revert these packages to previous versions in the 3.3.2 stable repo so those of us who want/need to install new hosts in our clusters aren't dead in the water waiting for 3.3.3?
Hi Robert, I think you can still install 3.3.2 on your clusters with the requirement of adding manually oython-cpopen before trying to install vdsm.
About 3.3.3, I think vdsm should really drop dependency on vdsm-python-cpopen: it's a package obsoleted by python-cpopen so there's no point in still requiring it especially if keeping that requirement still break dependency resolution.
I really wanted to avoid eliminating a subpackage during a micro release. That's impolite and surprising. But given the awkward yum bug, persistent dependency problems, and the current release delay, I give up.
Let's eliminate vdsm-python-cpopen from ovirt-3.3 branch, and require python-cpopen. Yaniv, Douglas: could you handle it?
Sure. Done: http://gerrit.ovirt.org/#/c/23942/
Acked. Could you cherry-pick it into dist-git and rebuild the ovirt-3.3.3 candidate (and without other changes that can wait for ovirt-3.3.4).
Let me know where I can get the new rpms, so I can add them to 3.3.3 repo and release :-)
On 02/01/2014 06:05 PM, Dan Kenigsberg wrote:
On Fri, Jan 31, 2014 at 04:16:54PM -0500, Douglas Schilling Landgraf wrote:
On 01/31/2014 05:17 AM, Dan Kenigsberg wrote:
On Fri, Jan 31, 2014 at 09:36:48AM +0100, Sandro Bonazzola wrote:
Il 30/01/2014 22:38, Robert Story ha scritto:
Can we revert these packages to previous versions in the 3.3.2 stable repo so those of us who want/need to install new hosts in our clusters aren't dead in the water waiting for 3.3.3?
Hi Robert, I think you can still install 3.3.2 on your clusters with the requirement of adding manually oython-cpopen before trying to install vdsm.
About 3.3.3, I think vdsm should really drop dependency on vdsm-python-cpopen: it's a package obsoleted by python-cpopen so there's no point in still requiring it especially if keeping that requirement still break dependency resolution.
I really wanted to avoid eliminating a subpackage during a micro release. That's impolite and surprising. But given the awkward yum bug, persistent dependency problems, and the current release delay, I give up.
Let's eliminate vdsm-python-cpopen from ovirt-3.3 branch, and require python-cpopen. Yaniv, Douglas: could you handle it?
Sure. Done: http://gerrit.ovirt.org/#/c/23942/
Acked. Could you cherry-pick it into dist-git and rebuild the ovirt-3.3.3 candidate (and without other changes that can wait for ovirt-3.3.4).
vdsm-4.13.3-3 available at:
F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6484103 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6484142 EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6484377
Patch included in this version: spec: replace requires vdsm-python-cpopen http://gerrit.ovirt.org/23942
On Thu, Jan 30, 2014 at 10:38 PM, Robert Story wrote:
Can we revert these packages to previous versions in the 3.3.2 stable repo so those of us who want/need to install new hosts in our clusters aren't dead in the water waiting for 3.3.3?
Also because 3.3.3, at least based on beta1 and rc, seems the best ever and the more stable. I need yet to stress test snapshots functionalities and some other things but in general it seems very ok, also in virtual disks mgmt. Just my opinion
Gianluca
Hi,
thanks for your reply.
So for a stable 3.3. deployment vdsm-python-cpopen would suffice but when I want to upgrade to 3.4. I'll need python-cpopen anyway.
I guess you got some version/deprecation problems in rpm/yum to properly replace vdsm-p-c with p-c.
To be a little bit more precise:
I want to know, which option should I chose if I want to deploy a 3.3.2 stable today, with the ability to upgrade to 3.4 somewhere in time:
a) install python-cpopen b) install vdsm-python-cpopen
and which downside each option has regarding upgrades, and if the different bugs in the different upgradepaths will get resolved until 3.4 release.
I think this should lead, in the end, to a stable 3.4 with python-cpopen installed instead of vdsm-python-cpopen.
The question is, again, if you would advice to install python-cpopen or vdsm-python-cpopen on 3.3.2 when you take into account the different upgrade bugs and if they get resolved until 3.4 release, assuming that for the 3.3. installation there is no difference if you install python-cpopen or vdsm-python-cpopen.
Thank you.
Am 30.01.2014 10:20, schrieb Dan Kenigsberg:
python-cpopen includes some improvements and bug fixes, that are going to be needed in ovirt-3.4. vdsm-python-cpopen is shipped by ovirt-3.3.
python-cpopen wast intended to deprecate and replace vdsm-python-cpopen, but we have had way too many issues trying to do that properly in rpm/yum. Most of the bugs are ours, at least one is yum's.
At the moment, the existence of python-cpopen in Fedora confuses `yum install vdsm`.
To avoid this unfortunate delay, we can either include python-cpopen in ovirt-stable or exclude vdsm-python-cpopen from there. Both options are unfavorable, but so is continuing to wait.
Regards, Dan.
vdsm-devel@lists.fedorahosted.org