Building vdsm within Fedora
Since Vdsm was open-sourced, it was built and deployed via Fedora. Recently [http://gerrit.ovirt.org/31214] vdsm introduced a spec-file dependency onf qemu-kvm-rhev, and considered to backport it to the ovirt-3.4 brach. Requiring qemu-kvm-rhev, which is not part of Fedora's EPEL6 branch, violates Fedora's standards. So basically we have two options: 1. Revert the qemu-kvm-rhev dependency. 2. Drop vdsm from EPEL6 (or completely from Fedora); ship Vdsm only within the oVirt repositories. A third option would be to have one rpm, with qemu-kvm-rhev, shipped in ovirt, and another without it - shipped in Fedora. I find this overly complex and confusing. I favor option 2. The Fedora deployment platform served us well for a long time, but now that ovirt is maturing, we no longer need it for building vdsm. This has the added benefit of removing the need to pass through Fedora's ghastly gateway when adding a Vdsm dependency. Sandro, what should be done in order to build Vdsm by ovirt, occording to the most up-to-date tag in a stable branch? Does anybody object this? If no one does, we would stop updating Vdsm in Fedora, and obsolete it in the future. Regards, Dan.
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com>, devel@ovirt.org, fsimonce@redhat.com, dougsland@redhat.com Cc: "users" <users@ovirt.org> Sent: Wednesday, September 24, 2014 12:21:18 AM Subject: [ovirt-devel] Building vdsm within Fedora
Since Vdsm was open-sourced, it was built and deployed via Fedora.
Recently [http://gerrit.ovirt.org/31214] vdsm introduced a spec-file dependency onf qemu-kvm-rhev, and considered to backport it to the ovirt-3.4 brach.
Requiring qemu-kvm-rhev, which is not part of Fedora's EPEL6 branch, violates Fedora's standards.
So basically we have two options:
4 options...
1. Revert the qemu-kvm-rhev dependency.
Why did we merge a package which is not available on all supported platforms?
2. Drop vdsm from EPEL6 (or completely from Fedora); ship Vdsm only within the oVirt repositories.
3. Package qemu-kvm-rhev in Fedora This is the root cause, lets fix it. 4. Until 3 is fixed, require qemu-kvm-rhev where it exists, otherwise on qemu-kvm.
I favor option 2. The Fedora deployment platform served us well for a long time, but now that ovirt is maturing, we no longer need it for building vdsm. This has the added benefit of removing the need to pass through Fedora's ghastly gateway when adding a Vdsm dependency.
This is the wrong direction. We want ovirt in all distributions. You suggest to have it in no distribution :-)
Does anybody object this? If no one does, we would stop updating Vdsm in Fedora, and obsolete it in the future.
I do Nir
Il 24/09/2014 00:21, Nir Soffer ha scritto:
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com>, devel@ovirt.org, fsimonce@redhat.com, dougsland@redhat.com Cc: "users" <users@ovirt.org> Sent: Wednesday, September 24, 2014 12:21:18 AM Subject: [ovirt-devel] Building vdsm within Fedora
Since Vdsm was open-sourced, it was built and deployed via Fedora.
Recently [http://gerrit.ovirt.org/31214] vdsm introduced a spec-file dependency onf qemu-kvm-rhev, and considered to backport it to the ovirt-3.4 brach.
Requiring qemu-kvm-rhev, which is not part of Fedora's EPEL6 branch, violates Fedora's standards.
So basically we have two options:
4 options...
1. Revert the qemu-kvm-rhev dependency.
Why did we merge a package which is not available on all supported platforms?
2. Drop vdsm from EPEL6 (or completely from Fedora); ship Vdsm only within the oVirt repositories.
3. Package qemu-kvm-rhev in Fedora
in EPEL. But if you're going to add it to EPEL please ensure it doesn't violate https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies
This is the root cause, lets fix it.
4. Until 3 is fixed, require qemu-kvm-rhev where it exists, otherwise on qemu-kvm.
Which is basically 1 only for the fedora packaging, keeping the dep on ovirt packaging.
I favor option 2. The Fedora deployment platform served us well for a long time, but now that ovirt is maturing, we no longer need it for building vdsm. This has the added benefit of removing the need to pass through Fedora's ghastly gateway when adding a Vdsm dependency.
This is the wrong direction. We want ovirt in all distributions. You suggest to have it in no distribution :-)
I tend to agree with Nir.
Sandro, what should be done in order to build Vdsm by ovirt, occording to the most up-to-date tag in a stable branch?
currently we're using mock for building packages whenever we can use it. for vdsm I created a yaml job here: http://gerrit.ovirt.org/32512 once it's merged you can build from git tag.
Does anybody object this? If no one does, we would stop updating Vdsm in Fedora, and obsolete it in the future.
I do
Nir
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com>, devel@ovirt.org, fsimonce@redhat.com, dougsland@redhat.com Cc: "Sven Kieske" <s.kieske@mittwald.de>, "users" <users@ovirt.org> Sent: Tuesday, September 23, 2014 11:21:18 PM Subject: Building vdsm within Fedora
Since Vdsm was open-sourced, it was built and deployed via Fedora.
Recently [http://gerrit.ovirt.org/31214] vdsm introduced a spec-file dependency onf qemu-kvm-rhev, and considered to backport it to the ovirt-3.4 brach.
Requiring qemu-kvm-rhev, which is not part of Fedora's EPEL6 branch, violates Fedora's standards.
So basically we have two options:
1. Revert the qemu-kvm-rhev dependency. 2. Drop vdsm from EPEL6 (or completely from Fedora); ship Vdsm only within the oVirt repositories.
A third option would be to have one rpm, with qemu-kvm-rhev, shipped in ovirt, and another without it - shipped in Fedora. I find this overly complex and confusing.
I think that until now (centos6) we were using qemu-kvm/qemu-img in the spec file and then the ovirt repository was distributing qemu-*-rhev from: http://resources.ovirt.org/pub/ovirt-3.4-snapshot/rpm/el6/x86_64/ It this not possible with centos7? Any problem with that? I find being in fedora a way to keep the spec file and the rpm updated and as clean as possible. -- Federico
Il 24/09/2014 08:53, Federico Simoncelli ha scritto:
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com>, devel@ovirt.org, fsimonce@redhat.com, dougsland@redhat.com Cc: "Sven Kieske" <s.kieske@mittwald.de>, "users" <users@ovirt.org> Sent: Tuesday, September 23, 2014 11:21:18 PM Subject: Building vdsm within Fedora
Since Vdsm was open-sourced, it was built and deployed via Fedora.
Recently [http://gerrit.ovirt.org/31214] vdsm introduced a spec-file dependency onf qemu-kvm-rhev, and considered to backport it to the ovirt-3.4 brach.
Requiring qemu-kvm-rhev, which is not part of Fedora's EPEL6 branch, violates Fedora's standards.
So basically we have two options:
1. Revert the qemu-kvm-rhev dependency. 2. Drop vdsm from EPEL6 (or completely from Fedora); ship Vdsm only within the oVirt repositories.
A third option would be to have one rpm, with qemu-kvm-rhev, shipped in ovirt, and another without it - shipped in Fedora. I find this overly complex and confusing.
I think that until now (centos6) we were using qemu-kvm/qemu-img in the spec file and then the ovirt repository was distributing qemu-*-rhev from:
http://resources.ovirt.org/pub/ovirt-3.4-snapshot/rpm/el6/x86_64/
It this not possible with centos7? Any problem with that?
We're shipping qemu-kvm-rhev on 3.4, 3.5 and master for EL6 and EL7. The issue is that if you don't enable ovirt, epel fails repository closure.
I find being in fedora a way to keep the spec file and the rpm updated and as clean as possible.
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
----- Original Message -----
From: "Sandro Bonazzola" <sbonazzo@redhat.com> To: "Federico Simoncelli" <fsimonce@redhat.com>, "Dan Kenigsberg" <danken@redhat.com> Cc: devel@ovirt.org, dougsland@redhat.com, "Sven Kieske" <s.kieske@mittwald.de>, "users" <users@ovirt.org> Sent: Wednesday, September 24, 2014 9:00:20 AM Subject: Re: Building vdsm within Fedora
Il 24/09/2014 08:53, Federico Simoncelli ha scritto:
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com>, devel@ovirt.org, fsimonce@redhat.com, dougsland@redhat.com Cc: "Sven Kieske" <s.kieske@mittwald.de>, "users" <users@ovirt.org> Sent: Tuesday, September 23, 2014 11:21:18 PM Subject: Building vdsm within Fedora
Since Vdsm was open-sourced, it was built and deployed via Fedora.
Recently [http://gerrit.ovirt.org/31214] vdsm introduced a spec-file dependency onf qemu-kvm-rhev, and considered to backport it to the ovirt-3.4 brach.
Requiring qemu-kvm-rhev, which is not part of Fedora's EPEL6 branch, violates Fedora's standards.
So basically we have two options:
1. Revert the qemu-kvm-rhev dependency. 2. Drop vdsm from EPEL6 (or completely from Fedora); ship Vdsm only within the oVirt repositories.
A third option would be to have one rpm, with qemu-kvm-rhev, shipped in ovirt, and another without it - shipped in Fedora. I find this overly complex and confusing.
I think that until now (centos6) we were using qemu-kvm/qemu-img in the spec file and then the ovirt repository was distributing qemu-*-rhev from:
http://resources.ovirt.org/pub/ovirt-3.4-snapshot/rpm/el6/x86_64/
It this not possible with centos7? Any problem with that?
We're shipping qemu-kvm-rhev on 3.4, 3.5 and master for EL6 and EL7. The issue is that if you don't enable ovirt, epel fails repository closure.
You probably missed the first part "we were using qemu-kvm/qemu-img in the spec file". In that case you won't fail in any requirement. Basically the question is: was there any problem on centos6 before committing http://gerrit.ovirt.org/31214 ? If not, why don't we do the same for centos7? -- Federico
On 24/09/14 09:13, Federico Simoncelli wrote:
You probably missed the first part "we were using qemu-kvm/qemu-img in the spec file". In that case you won't fail in any requirement.
Basically the question is: was there any problem on centos6 before committing http://gerrit.ovirt.org/31214 ?
Of course there was a problem, please follow the link in this very commit to the according bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1127763 In short: you can not use live snapshots without this updated spec file. And it's a PITA to install this package by hand, you must track it's versions yourself etc pp. you basically lose all the stuff a proper spec file gives you. PS: I also don't get the "we want to get vdsm in every distribution" a) it was never in any distro, it was in epel, which is a third party repository anyway, so you can just provide it via ovirt repo imho. b) no one packages vdsm for debian, ubuntu, gentoo, arch, suse, $nameyourdistro or I completely missed it, so why treat fedora in a special way? Don't misunderstand me, it would be cool if you have packages for every distro, or even bsd based stuff, but I think this is still a long way. c) will anyone use vdsm without ovirt? is this even possible? so imho you need ovirt repos anyway? -- 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
----- Original Message -----
From: "Sven Kieske" <s.kieske@mittwald.de> To: devel@ovirt.org, "users" <users@ovirt.org> Sent: Wednesday, September 24, 2014 10:44:17 AM Subject: Re: [ovirt-users] Building vdsm within Fedora
On 24/09/14 09:13, Federico Simoncelli wrote:
You probably missed the first part "we were using qemu-kvm/qemu-img in the spec file". In that case you won't fail in any requirement.
Basically the question is: was there any problem on centos6 before committing http://gerrit.ovirt.org/31214 ?
Of course there was a problem, please follow the link in this very commit to the according bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1127763
In short: you can not use live snapshots without this updated spec file.
And it's a PITA to install this package by hand, you must track it's versions yourself etc pp. you basically lose all the stuff a proper spec file gives you.
PS: I also don't get the "we want to get vdsm in every distribution" a) it was never in any distro, it was in epel, which is a third party repository anyway, so you can just provide it via ovirt repo imho. b) no one packages vdsm for debian, ubuntu, gentoo, arch, suse, $nameyourdistro or I completely missed it, so why treat fedora in a special way? Don't misunderstand me, it would be cool if you have packages for every distro, or even bsd based stuff, but I think this is still a long way. c) will anyone use vdsm without ovirt? is this even possible? so imho you need ovirt repos anyway?
People think that distribution is monolithic. While in fact most, including fedora, are modular. Alon
----- Original Message -----
From: "Sven Kieske" <s.kieske@mittwald.de> To: devel@ovirt.org, "users" <users@ovirt.org> Sent: Wednesday, September 24, 2014 9:44:17 AM Subject: Re: [ovirt-devel] Building vdsm within Fedora
On 24/09/14 09:13, Federico Simoncelli wrote:
You probably missed the first part "we were using qemu-kvm/qemu-img in the spec file". In that case you won't fail in any requirement.
Basically the question is: was there any problem on centos6 before committing http://gerrit.ovirt.org/31214 ?
Of course there was a problem, please follow the link in this very commit to the according bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1127763
In short: you can not use live snapshots without this updated spec file.
And it's a PITA to install this package by hand, you must track it's versions yourself etc pp. you basically lose all the stuff a proper spec file gives you.
As soon as you have the ovirt repository installed there shouldn't be any reason for you to have any of these problems. Sandro, is there any reason why the rpm available here: http://resources.ovirt.org/pub/ovirt-3.4/rpm/el6/x86_64/ are not published here? http://resources.ovirt.org/releases/3.4/rpm/el6/x86_64/ Is there any additional repository (that provides qemu-*-rhev) that we are missing from the ovirt.repo file? -- Federico
Il 24/09/2014 10:35, Federico Simoncelli ha scritto:
----- Original Message -----
From: "Sven Kieske" <s.kieske@mittwald.de> To: devel@ovirt.org, "users" <users@ovirt.org> Sent: Wednesday, September 24, 2014 9:44:17 AM Subject: Re: [ovirt-devel] Building vdsm within Fedora
On 24/09/14 09:13, Federico Simoncelli wrote:
You probably missed the first part "we were using qemu-kvm/qemu-img in the spec file". In that case you won't fail in any requirement.
Basically the question is: was there any problem on centos6 before committing http://gerrit.ovirt.org/31214 ?
Of course there was a problem, please follow the link in this very commit to the according bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1127763
In short: you can not use live snapshots without this updated spec file.
And it's a PITA to install this package by hand, you must track it's versions yourself etc pp. you basically lose all the stuff a proper spec file gives you.
As soon as you have the ovirt repository installed there shouldn't be any reason for you to have any of these problems.
Sandro, is there any reason why the rpm available here:
http://resources.ovirt.org/pub/ovirt-3.4/rpm/el6/x86_64/
are not published here?
this second link points to the previous layout, abandoned since we moved from /releases to /pub. /releases is still around for historical purpose, I think we should consider to drop it at some point avoinding confusion or renaming it to something that make it clear that it shouldn't be used anymore.
Is there any additional repository (that provides qemu-*-rhev) that we are missing from the ovirt.repo file?
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
----- Original Message -----
From: "Sandro Bonazzola" <sbonazzo@redhat.com> To: "Federico Simoncelli" <fsimonce@redhat.com> Cc: devel@ovirt.org, "users" <users@ovirt.org>, "Sven Kieske" <s.kieske@mittwald.de> Sent: Wednesday, September 24, 2014 11:01:35 AM Subject: Re: [ovirt-devel] Building vdsm within Fedora
Il 24/09/2014 10:35, Federico Simoncelli ha scritto:
----- Original Message -----
From: "Sven Kieske" <s.kieske@mittwald.de> To: devel@ovirt.org, "users" <users@ovirt.org> Sent: Wednesday, September 24, 2014 9:44:17 AM Subject: Re: [ovirt-devel] Building vdsm within Fedora
On 24/09/14 09:13, Federico Simoncelli wrote:
You probably missed the first part "we were using qemu-kvm/qemu-img in the spec file". In that case you won't fail in any requirement.
Basically the question is: was there any problem on centos6 before committing http://gerrit.ovirt.org/31214 ?
Of course there was a problem, please follow the link in this very commit to the according bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1127763
In short: you can not use live snapshots without this updated spec file.
And it's a PITA to install this package by hand, you must track it's versions yourself etc pp. you basically lose all the stuff a proper spec file gives you.
As soon as you have the ovirt repository installed there shouldn't be any reason for you to have any of these problems.
Sandro, is there any reason why the rpm available here:
http://resources.ovirt.org/pub/ovirt-3.4/rpm/el6/x86_64/
are not published here?
this second link points to the previous layout, abandoned since we moved from /releases to /pub. /releases is still around for historical purpose, I think we should consider to drop it at some point avoinding confusion or renaming it to something that make it clear that it shouldn't be used anymore.
Sven can you let us know if you still have any problem using: http://resources.ovirt.org/pub/yum-repo/ovirt-release34.rpm (which should contain the correct ovirt.repo) Thanks, -- Federico
Il 24/09/2014 09:44, Sven Kieske ha scritto:
On 24/09/14 09:13, Federico Simoncelli wrote:
You probably missed the first part "we were using qemu-kvm/qemu-img in the spec file". In that case you won't fail in any requirement.
Basically the question is: was there any problem on centos6 before committing http://gerrit.ovirt.org/31214 ?
Federico: as we checked a few minutes ago, it seems there's no problem in requiring qemu-kvm/qemu-img in the spec file. Only issue is that if non rhev version is installed a manual "yum update" is required for moving to the rhevm version.
Of course there was a problem, please follow the link in this very commit to the according bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1127763
In short: you can not use live snapshots without this updated spec file.
And it's a PITA to install this package by hand, you must track it's versions yourself etc pp. you basically lose all the stuff a proper spec file gives you.
Well, since the -rhev package is now available in 3.4, 3.5 and master repos it shouldn't be a PITA anymore.
PS: I also don't get the "we want to get vdsm in every distribution" a) it was never in any distro, it was in epel, which is a third party repository anyway, so you can just provide it via ovirt repo imho. b) no one packages vdsm for debian, ubuntu, gentoo, arch, suse, $nameyourdistro or I completely missed it, so why treat fedora in a special way? Don't misunderstand me, it would be cool if you have packages for every distro, or even bsd based stuff, but I think this is still a long way. c) will anyone use vdsm without ovirt? is this even possible? so imho you need ovirt repos anyway?
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
On 24/09/14 10:57, Sandro Bonazzola wrote:
Well, since the -rhev package is now available in 3.4, 3.5 and master repos it shouldn't be a PITA anymore.
Thanks for the clarification :) -- 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 24.09.2014 10:57, Sandro Bonazzola wrote:
Il 24/09/2014 09:44, Sven Kieske ha scritto:
On 24/09/14 09:13, Federico Simoncelli wrote:
You probably missed the first part "we were using qemu-kvm/qemu-img in the spec file". In that case you won't fail in any requirement.
Basically the question is: was there any problem on centos6 before committing http://gerrit.ovirt.org/31214 ?
Federico: as we checked a few minutes ago, it seems there's no problem in requiring qemu-kvm/qemu-img in the spec file. Only issue is that if non rhev version is installed a manual "yum update" is required for moving to the rhevm version. Indeed, I was about to complain in this thread myself ;) - Also, a 'yum install qemu-kvm-rhev' might be more "ovirt-way" and works the same.
Of course there was a problem, please follow the link in this very commit to the according bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1127763
In short: you can not use live snapshots without this updated spec file.
And it's a PITA to install this package by hand, you must track it's versions yourself etc pp. you basically lose all the stuff a proper spec file gives you. Well, since the -rhev package is now available in 3.4, 3.5 and master repos it shouldn't be a PITA anymore.
PS: I also don't get the "we want to get vdsm in every distribution" a) it was never in any distro, it was in epel, which is a third party repository anyway, so you can just provide it via ovirt repo imho. b) no one packages vdsm for debian, ubuntu, gentoo, arch, suse, $nameyourdistro or I completely missed it, so why treat fedora in a special way? Don't misunderstand me, it would be cool if you have packages for every distro, or even bsd based stuff, but I think this is still a long way. c) will anyone use vdsm without ovirt? is this even possible? so imho you need ovirt repos anyway?
-- Daniel Helgenberger m box bewegtbild GmbH P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19 D-10115 BERLIN www.m-box.de www.monkeymen.tv Geschäftsführer: Martin Retschitzegger / Michaela Göllner Handeslregister: Amtsgericht Charlottenburg / HRB 112767
On Wed, Sep 24, 2014 at 10:57:21AM +0200, Sandro Bonazzola wrote:
Il 24/09/2014 09:44, Sven Kieske ha scritto:
On 24/09/14 09:13, Federico Simoncelli wrote:
You probably missed the first part "we were using qemu-kvm/qemu-img in the spec file". In that case you won't fail in any requirement.
Basically the question is: was there any problem on centos6 before committing http://gerrit.ovirt.org/31214 ?
Federico: as we checked a few minutes ago, it seems there's no problem in requiring qemu-kvm/qemu-img in the spec file. Only issue is that if non rhev version is installed a manual "yum update" is required for moving to the rhevm version.
Right. Without the patch, RPM does not enforce qemu-kvm-rhev. So our code has to check for qemu-kvm-rhev functionality, instead of knowing that it is there. Furthermore, we had several reports of users finding themselves without qemu-kvm-rhev on their node, and not understanding why they do not have live merge.
Of course there was a problem, please follow the link in this very commit to the according bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1127763
In short: you can not use live snapshots without this updated spec file.
And it's a PITA to install this package by hand, you must track it's versions yourself etc pp. you basically lose all the stuff a proper spec file gives you.
Well, since the -rhev package is now available in 3.4, 3.5 and master repos it shouldn't be a PITA anymore.
PS: I also don't get the "we want to get vdsm in every distribution" a) it was never in any distro, it was in epel, which is a third party repository anyway, so you can just provide it via ovirt repo imho.
Historically, Vdsm has been part of Fedora before it has been part of ovirt! https://bugzilla.redhat.com/show_bug.cgi?id=745510 The EPEL build was added much later
b) no one packages vdsm for debian, ubuntu, gentoo, arch, suse, $nameyourdistro or I completely missed it, so why treat fedora in a special way? Don't misunderstand me, it would be cool if you have packages for every distro, or even bsd based stuff, but I think this is still a long way.
Indeed. But it would be even longer if we take my suggested step backwards.
c) will anyone use vdsm without ovirt? is this even possible? so imho you need ovirt repos anyway?
I don't belive Vdsm is soon to be used by anything outside oVirt. But if software purists win, oVirt would publish only tarballs. Fedora/Debian/whatever would build, package, and deploy them all, and the ovirt repo would become redundant. I did not expect to hear much support for keeping Vdsm in Fedora. Given what I've heard, how about taking the in-between road? - Keep Vdsm in Fedora, abiding to Fedora rules. - Hope that Engine and qemu-kvm-rhev join, too. - Until they do, build vdsm.rpm with non-Fedora quirks (such as the qemu-kvm-rhev requirement) http://gerrit.ovirt.org/33367 spec: do not require qemu-kvm-rhev on Fedora http://gerrit.ovirt.org/33368 spec: allow all archs in Fedora Dan.
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com> Cc: crobinso@redhat.com, "users" <users@ovirt.org>, devel@ovirt.org Sent: Thursday, September 25, 2014 4:06:01 PM Subject: Re: [ovirt-users] [ovirt-devel] Building vdsm within Fedora ... I did not expect to hear much support for keeping Vdsm in Fedora. Given what I've heard, how about taking the in-between road?
- Keep Vdsm in Fedora, abiding to Fedora rules. - Hope that Engine and qemu-kvm-rhev join, too. - Until they do, build vdsm.rpm with non-Fedora quirks (such as the qemu-kvm-rhev requirement)
http://gerrit.ovirt.org/33367 spec: do not require qemu-kvm-rhev on Fedora http://gerrit.ovirt.org/33368 spec: allow all archs in Fedora
Looks good to me. Nir
On 09/25/2014 04:06 PM, Dan Kenigsberg wrote:
I don't belive Vdsm is soon to be used by anything outside oVirt. But if software purists win, oVirt would publish only tarballs. Fedora/Debian/whatever would build, package, and deploy them all, and the ovirt repo would become redundant.
I did not expect to hear much support for keeping Vdsm in Fedora. Given what I've heard, how about taking the in-between road?
- Keep Vdsm in Fedora, abiding to Fedora rules. - Hope that Engine and qemu-kvm-rhev join, too.
we did the work to add engine, but it was useless without its gui, and was impossible to add gwt to fedora. qemu-kvm-rhev is not needed in fedora as fedora has a full blown qemu-kvm with all features enabled. you only need qemu-kvm-rhev on .el6 hosts.
- Until they do, build vdsm.rpm with non-Fedora quirks (such as the qemu-kvm-rhev requirement)
On Fri, Sep 26, 2014 at 12:42:05PM +0300, Itamar Heim wrote:
On 09/25/2014 04:06 PM, Dan Kenigsberg wrote:
I don't belive Vdsm is soon to be used by anything outside oVirt. But if software purists win, oVirt would publish only tarballs. Fedora/Debian/whatever would build, package, and deploy them all, and the ovirt repo would become redundant.
I did not expect to hear much support for keeping Vdsm in Fedora. Given what I've heard, how about taking the in-between road?
- Keep Vdsm in Fedora, abiding to Fedora rules. - Hope that Engine and qemu-kvm-rhev join, too.
we did the work to add engine, but it was useless without its gui, and was impossible to add gwt to fedora. qemu-kvm-rhev is not needed in fedora as fedora has a full blown qemu-kvm with all features enabled. you only need qemu-kvm-rhev on .el6 hosts.
I meant that qemu-kvm-rhev is missing from Fedora's EPEL6/7 branches. As such, Vdsm cannot require it in its own EPEL build.
- Until they do, build vdsm.rpm with non-Fedora quirks (such as the qemu-kvm-rhev requirement)
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com> Cc: crobinso@redhat.com, "users" <users@ovirt.org>, devel@ovirt.org Sent: Thursday, September 25, 2014 3:06:01 PM Subject: Re: [ovirt-devel] [ovirt-users] Building vdsm within Fedora
On Wed, Sep 24, 2014 at 10:57:21AM +0200, Sandro Bonazzola wrote:
Il 24/09/2014 09:44, Sven Kieske ha scritto:
On 24/09/14 09:13, Federico Simoncelli wrote:
You probably missed the first part "we were using qemu-kvm/qemu-img in the spec file". In that case you won't fail in any requirement.
Basically the question is: was there any problem on centos6 before committing http://gerrit.ovirt.org/31214 ?
Federico: as we checked a few minutes ago, it seems there's no problem in requiring qemu-kvm/qemu-img in the spec file. Only issue is that if non rhev version is installed a manual "yum update" is required for moving to the rhevm version.
Right. Without the patch, RPM does not enforce qemu-kvm-rhev. So our code has to check for qemu-kvm-rhev functionality, instead of knowing that it is there. Furthermore, we had several reports of users finding themselves without qemu-kvm-rhev on their node, and not understanding why they do not have live merge.
Live merge? The biggest problem with live merge is libvirt not qemu. Anyway the qemu-kvm/qemu-kvm-rhev problem is relevant only for centos and centos has a specific way to address these special needs: http://www.centos.org/variants/ """ A CentOS variant is a special edition of CentOS Linux that starts with the core distribution, then replaces or supplements a specific subset of packages. This may include replacing everything down to the kernel, networking, and other subsystems. """ I think the plan was to have our own centos variant (shipping qemu-kvm-rhev). I remember Doron participated to the centos meetings but I don't remember the outcome. -- Federico
On Fri, Sep 26, 2014 at 05:42:41AM -0400, Federico Simoncelli wrote:
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com> Cc: crobinso@redhat.com, "users" <users@ovirt.org>, devel@ovirt.org Sent: Thursday, September 25, 2014 3:06:01 PM Subject: Re: [ovirt-devel] [ovirt-users] Building vdsm within Fedora
On Wed, Sep 24, 2014 at 10:57:21AM +0200, Sandro Bonazzola wrote:
Il 24/09/2014 09:44, Sven Kieske ha scritto:
On 24/09/14 09:13, Federico Simoncelli wrote:
You probably missed the first part "we were using qemu-kvm/qemu-img in the spec file". In that case you won't fail in any requirement.
Basically the question is: was there any problem on centos6 before committing http://gerrit.ovirt.org/31214 ?
Federico: as we checked a few minutes ago, it seems there's no problem in requiring qemu-kvm/qemu-img in the spec file. Only issue is that if non rhev version is installed a manual "yum update" is required for moving to the rhevm version.
Right. Without the patch, RPM does not enforce qemu-kvm-rhev. So our code has to check for qemu-kvm-rhev functionality, instead of knowing that it is there. Furthermore, we had several reports of users finding themselves without qemu-kvm-rhev on their node, and not understanding why they do not have live merge.
Live merge? The biggest problem with live merge is libvirt not qemu.
Sorry, I meant to say live snapshot and refer to http://gerrit.ovirt.org/26149 reporting to Engine if it's available.
Anyway the qemu-kvm/qemu-kvm-rhev problem is relevant only for centos and centos has a specific way to address these special needs:
http://www.centos.org/variants/
""" A CentOS variant is a special edition of CentOS Linux that starts with the core distribution, then replaces or supplements a specific subset of packages. This may include replacing everything down to the kernel, networking, and other subsystems. """
I think the plan was to have our own centos variant (shipping qemu-kvm-rhev). I remember Doron participated to the centos meetings but I don't remember the outcome.
That would be lovely. EPEL's vdsm can then ship there, in case Fedora cannot depend on a centos variant. Dan.
participants (8)
-
Alon Bar-Lev -
Dan Kenigsberg -
Daniel Helgenberger -
Federico Simoncelli -
Itamar Heim -
Nir Soffer -
Sandro Bonazzola -
Sven Kieske