[Users] ovirt-3.3.3 release postponed due to blockers
Hi, oVirt 3.3.3 release need to be postponed. A recent release of python-cpopen-1.3 is breaking dependency resolution on EL6 and F19 so vdsm can't be installed and node can't be composed. A recent change in vdsm-python-cpopen added the needed conflict against python-cpopen and removed Provides / Obsoletes on python-cpopen. But no new releases of python-cpopen is available fixing the correct Provides / Obsoletes pair. oVirt 3.3.2 / stable is affected too. Please fix Bug 1056470 - python-cpopen-1.3 is not providing obsoleted package. Bug 1056464 - python-cpopen-1.3 is not providing obsoleted package. ASAP. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
Hi, I do not see any Bug tracking this behaviour on EL6. Is there none needed or will this not get resolved for EL6? Is there a known workaround? I already asked this in a different BZ, I think: Is the "full blown host" node install for EL6 also affected? I did not get any reply to this question. I hope someone can share some light on this. Thank you. Am 28.01.2014 13:55, schrieb Sandro Bonazzola:
Hi, oVirt 3.3.3 release need to be postponed. A recent release of python-cpopen-1.3 is breaking dependency resolution on EL6 and F19 so vdsm can't be installed and node can't be composed. A recent change in vdsm-python-cpopen added the needed conflict against python-cpopen and removed Provides / Obsoletes on python-cpopen. But no new releases of python-cpopen is available fixing the correct Provides / Obsoletes pair.
oVirt 3.3.2 / stable is affected too.
Please fix Bug 1056470 - python-cpopen-1.3 is not providing obsoleted package. Bug 1056464 - python-cpopen-1.3 is not providing obsoleted package. ASAP.
-- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
Il 28/01/2014 14:26, Sven Kieske ha scritto:
Hi,
I do not see any Bug tracking this behaviour on EL6. Is there none needed or will this not get resolved for EL6?
the rpm built for Fedora is the same build for EPEL so I think it may be enough having the one opened against Fedora.
Is there a known workaround?
You can manually install vdsm-python-cpopen, this will introduce conflict on python-cpopen which shouldn't be pulled in anymore
I already asked this in a different BZ, I think:
Is the "full blown host" node install for EL6 also affected?
Fabian?
I did not get any reply to this question.
I hope someone can share some light on this.
Thank you.
Am 28.01.2014 13:55, schrieb Sandro Bonazzola:
Hi, oVirt 3.3.3 release need to be postponed. A recent release of python-cpopen-1.3 is breaking dependency resolution on EL6 and F19 so vdsm can't be installed and node can't be composed. A recent change in vdsm-python-cpopen added the needed conflict against python-cpopen and removed Provides / Obsoletes on python-cpopen. But no new releases of python-cpopen is available fixing the correct Provides / Obsoletes pair.
oVirt 3.3.2 / stable is affected too.
Please fix Bug 1056470 - python-cpopen-1.3 is not providing obsoleted package. Bug 1056464 - python-cpopen-1.3 is not providing obsoleted package. ASAP.
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
--=-yKIfNoj1hv24/93BskRn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Am Dienstag, den 28.01.2014, 14:44 +0100 schrieb Sandro Bonazzola:
=20 I already asked this in a different BZ, I think: =20 Is the "full blown host" node install for EL6 also affected? =20 Fabian?
Hey, well - I ran into this while building Node, but you should also run into this when installing e.g. vdsm on a full blown host. You can probably workaround this problem on a full blown host by excluding some packages. But that's just a workaround and doesn't solve the problem. - fabian --=-yKIfNoj1hv24/93BskRn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAABAgAGBQJS57UyAAoJEC9+uOgSHVGUTMkP/jod1M+qoFuIMf6GmJbK/0Li ep0HGRaA1Nbkj8qGhwandlDE0Ik8JoRdfRICU5JxEUJsKao7FMQoD+ZZfC7ZcNKe EVqfjCFGgmyxI2K3fmUaoi+tKnR8tKdvbGHAY4IUVPj8hujI5u56I8zefNqMoYBl ht8rka+29sEd5mevV4EX/vejmlsMabAkkwXD21qe7Uxhw9ebZNex1RzDYFrShXCL A+9yH7Xvcy4SJw4vKiIUjcf8dOHDo3vrUHNeeXpv1BiyqY+gXkCX+pBSE5JyqlHF 11dp/1PkodOWNaO++WBaf19L5TRG1vzkf458OsAJ2hlLt/6UCcndN1LgRPkuz0FL HKARzsPHURDDG1p48iPairDcaNgeWdhgV3kDQ4CN++lB5YfDVDSTc/jvTqanbaXD gfq/DKtZ6o7xDsZesFT3IFTGwtsi0TFFc88X/kQ2yPiW5MErSlKZVdd8Q6xd2Nob F7WNBN/h/fXfC55v7UMf5FsHpz3Ns4ZdYvpDkYyLrzaWruZcdsPADhdgtK8RE7vy VTlUEFNKiIqtEBY0T7Fkc0o4DwivyVQvXJQi1/gspoKrIorH2rB9onZyT12Vf6UH yJkmAgTtX4RSBYZ7yE7J311PNlO1qDu3VobWspWbuVZYZvKt3kwNkxqJqui7U4cI 9NVV+Km8tFRY+XCM/leb =3OOC -----END PGP SIGNATURE----- --=-yKIfNoj1hv24/93BskRn--
Hi, and thanks for your fast reply. I know this does not fix it, but I'm preparing to deploy new hosts with EL6.5 and therefore need a workaround. I will try this out, thank you! Am 28.01.2014 14:48, schrieb Fabian Deutsch:
Am Dienstag, den 28.01.2014, 14:44 +0100 schrieb Sandro Bonazzola:
I already asked this in a different BZ, I think:
Is the "full blown host" node install for EL6 also affected?
Fabian?
Hey,
well - I ran into this while building Node, but you should also run into this when installing e.g. vdsm on a full blown host. You can probably workaround this problem on a full blown host by excluding some packages. But that's just a workaround and doesn't solve the problem.
- fabian
-- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
I found manually installing python-cpopen before adding a node in the engine is a viable workaround. This was on EL6.5 - Trey On Jan 28, 2014 7:57 AM, "Sven Kieske" <S.Kieske@mittwald.de> wrote:
Hi,
and thanks for your fast reply.
I know this does not fix it, but I'm preparing to deploy new hosts with EL6.5 and therefore need a workaround.
I will try this out, thank you!
Am 28.01.2014 14:48, schrieb Fabian Deutsch:
Am Dienstag, den 28.01.2014, 14:44 +0100 schrieb Sandro Bonazzola:
I already asked this in a different BZ, I think:
Is the "full blown host" node install for EL6 also affected?
Fabian?
Hey,
well - I ran into this while building Node, but you should also run into this when installing e.g. vdsm on a full blown host. You can probably workaround this problem on a full blown host by excluding some packages. But that's just a workaround and doesn't solve the problem.
- fabian
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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 ? 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
-- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
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
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
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
-- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
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.
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
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.
Having problems when testing power management (ipmilan, "lanplus=yes,power_wait=4") on ovirt 3.4 Error: Test Failed, VdcBLLException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: java.net.ConnectException: Connection refused (Failed with error VDS_NETWORK_ERROR and code 5022) engine.log: 2014-01-30 16:18:38,667 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_Worker-5) Command GetCapabilitiesVDSCommand(HostName = xxxx.xxxx.xxxxx, HostId = 6f32d094-c885-4280-8f18-149f4e0ed3ff, vds=Host[xxxx.xxxx.xxxx]) execution failed. Exception: VDSNetworkException: java.net.ConnectException: Connection refused 2014-01-30 16:18:41,905 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_Worker-86) Command GetCapabilitiesVDSCommand(HostName = xxxxx, HostId = 922cf3b2-9e5f-495b-bcc4-670acad956f6, vds=Host[xxxxx]) execution failed. Exception: VDSNetworkException: java.net.ConnectException: Connection refused We have supermicro ipmi and I tried pinging the ipmi from the node and that works ok. telnet from cli also works. Kind regards, Jorick Astrego
----- Original Message -----
From: "Jorick Astrego" <j.astrego@netbulae.eu> Cc: "users" <users@ovirt.org> Sent: Thursday, January 30, 2014 5:24:20 PM Subject: [Users] problem with power management in ovirt 3.4 cluster
Having problems when testing power management (ipmilan, "lanplus=yes,power_wait=4") on ovirt 3.4
Error: Test Failed, VdcBLLException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: java.net.ConnectException: Connection refused (Failed with error VDS_NETWORK_ERROR and code 5022)
engine.log:
2014-01-30 16:18:38,667 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_Worker-5) Command GetCapabilitiesVDSCommand(HostName = xxxx.xxxx.xxxxx, HostId = 6f32d094-c885-4280-8f18-149f4e0ed3ff, vds=Host[xxxx.xxxx.xxxx]) execution failed. Exception: VDSNetworkException: java.net.ConnectException: Connection refused 2014-01-30 16:18:41,905 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_Worker-86) Command GetCapabilitiesVDSCommand(HostName = xxxxx, HostId = 922cf3b2-9e5f-495b-bcc4-670acad956f6, vds=Host[xxxxx]) execution failed. Exception: VDSNetworkException: java.net.ConnectException: Connection refused
We have supermicro ipmi and I tried pinging the ipmi from the node and that works ok. telnet from cli also works.
Hi What are the statuses of the fenced host and other hosts in the same cluster/dc ? When do you get this error ? what is the scenario ? What do you get if you invoke the /usr/sbin/fence_ipmilan script directly from one of your hosts (with -o status) ??
Kind regards,
Jorick Astrego
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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.
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
--Sig_/fUwo9BEvqv/Zuzhy3Mjv2Am Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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,=20 SB> >=20 SB> > we found this yum bug and still struggling with more issuing SB> > according to the relation between those packages=20 SB> >=20 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> >=20 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> >=20 SB>=20 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 --Sig_/fUwo9BEvqv/Zuzhy3Mjv2Am Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlLqxkUACgkQ7/fVLLY1mnheswCgn8iUtI+8ej1p6wFiJJ+2cVoq xckAniQ28R+72D7EE7VsWntZYFPMuSuu =WVqR -----END PGP SIGNATURE----- --Sig_/fUwo9BEvqv/Zuzhy3Mjv2Am--
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
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
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?
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
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/ -- Cheers Douglas
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 :-) -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
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 -- Cheers Douglas
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
Thanks for the clarification! Am 30.01.2014 16:13, schrieb Yaniv Bronheim:
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. -- Mit freundlichen Grüßen / Regards
Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
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.
-- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
participants (11)
-
Dan Kenigsberg -
Douglas Schilling Landgraf -
Eli Mesika -
Fabian Deutsch -
Gianluca Cecchi -
Jorick Astrego -
Robert Story -
Sandro Bonazzola -
Sven Kieske -
Trey Dockendorf -
Yaniv Bronheim