qemu-kvm-rhev on EL machines for oVirt 3.4.z ?
Hi guys, We've recently started shipping qemu-kvm-rhev in oVirt 3.5's repos and requiring it by VDSM in order to allow oVirt users on EL server to enjoy the live snapshot capability which isn't available by the default qemu-kvm available for these machines [1]. On a different BZ, Sven raised the request to backport this to the 3.4.z stream as well [2]. In the discussion on the patch [3], Dan raised the concern that 3.4.z is a mature z-stream, and adding this dependency on resources.ovirt.org's repos will effectively blocks all vdsm updates for users which don't have these repos enabled in their production environments. We'd like to get some more input from the community before deciding whether to move forward with this or abandon the idea. Thanks, Allon [1] https://bugzilla.redhat.com/show_bug.cgi?id=1127763 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1127460#c36 [3] http://gerrit.ovirt.org/#/c/32239/ - Dan's first comment on patchset #2, from Sep 2 1:54 AM (couldn't find a way to link directly, sorry).
On 10/09/14 09:32, Allon Mureinik wrote:
Hi guys,
We've recently started shipping qemu-kvm-rhev in oVirt 3.5's repos and requiring it by VDSM in order to allow oVirt users on EL server to enjoy the live snapshot capability which isn't available by the default qemu-kvm available for these machines [1].
On a different BZ, Sven raised the request to backport this to the 3.4.z stream as well [2].
In the discussion on the patch [3], Dan raised the concern that 3.4.z is a mature z-stream, and adding this dependency on resources.ovirt.org's repos will effectively blocks all vdsm updates for users which don't have these repos enabled in their production environments.
I'm sorry but I don't understand this. If you would decide to backport this to 3.4.4 you surely would make the qemu-kvm-rhev package available in the 3.4.4 repository which is needed to upgrade to 3.4.4 anyway? So what would people prevent from using it?
From your mail I get the impression you want to release it for 3.4.4 but don't include it in 3.4.4 repo, just in 3.5 repo?
This doesn't make sense at all so I guess I'm missing a point here? Please explain this a little bit more, so I can understand your concern, thanks.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1127763 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1127460#c36 [3] http://gerrit.ovirt.org/#/c/32239/ - Dan's first comment on patchset #2, from Sep 2 1:54 AM (couldn't find a way to link directly, sorry).
-- 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 Wed, Sep 10, 2014 at 9:44 AM, Sven Kieske <s.kieske@mittwald.de> wrote:
In the discussion on the patch [3], Dan raised the concern that 3.4.z is a mature z-stream, and adding this dependency on resources.ovirt.org's repos will effectively blocks all vdsm updates for users which don't have these repos enabled in their production environments.
I'm sorry but I don't understand this.
Hello, I directly put here what I see Dan wrote in the link provided and that it seemed to me more a warning than a blocker.. (eventually he may add further content...) " Patch Set 2: I'm not sure that this is a good idea for a mature z-stream. If someone has installed ovirt-3.4 without enabling the resource.ovirt.org's repos, this patch effectively blocks all vdsm updates for him. If we really want this in ovirt-3.4.4, please explain why and warn about the downsides on users@ovirt.org. " I don't completely understand too... How could one have installed 3.4 without enabling resource.ovirt.org's repos? Afaik the most of us who used EL 6 for their infra, then in soe way installed the rhev qemu-kvm package or desired/asked to do so in some way... So I think that is this is clearly stated on release notes there should be no particular problem. Gianluca
------=_Part_20491922_1544569321.1410343158012 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message -----
From: "Gianluca Cecchi" <gianluca.cecchi@gmail.com> To: "Sven Kieske" <s.kieske@mittwald.de> Cc: "Allon Mureinik" <amureini@redhat.com>, "users" <users@ovirt.org> Sent: Wednesday, September 10, 2014 10:57:27 AM Subject: Re: [ovirt-users] qemu-kvm-rhev on EL machines for oVirt 3.4.z ?
On Wed, Sep 10, 2014 at 9:44 AM, Sven Kieske < s.kieske@mittwald.de > wrote:
In the discussion on the patch [3], Dan raised the concern that 3.4.z is a mature z-stream, and adding this dependency on resources.ovirt.org 's repos will effectively blocks all vdsm updates for users which don't have these repos enabled in their production environments.
I'm sorry but I don't understand this.
Hello, I directly put here what I see Dan wrote in the link provided and that it seemed to me more a warning than a blocker.. (eventually he may add further content...)
"
Patch Set 2:
I'm not sure that this is a good idea for a mature z-stream. If someone has installed ovirt-3.4 without enabling the resource.ovirt.org 's repos, this patch effectively blocks all vdsm updates for him.
If we really want this in ovirt-3.4.4, please explain why and warn about the downsides on users@ovirt.org . "
I don't completely understand too... How could one have installed 3.4 without enabling resource.ovirt.org 's repos? Afaik the most of us who used EL 6 for their infra, then in soe way installed the rhev qemu-kvm package or desired/asked to do so in some way...
So I think that is this is clearly stated on release notes there should be no particular problem.
Gianluca
If we decide to move forward with this patch, we'll definitely provide qemu-kvm-rhev in the repo - the concern was indeed for users who don't have this enabled. Unlike 3.5, the 3.4.z repo doesn't seem to provide any "3rd parties" that can't be built from oVirt's sources - so, theoretically, it can be installed without the repo enabled - and the discussion here is whether this is an interesting usecase or not. My personal tendency is to go forward (with a release note, as suggested), but as noted, there is some disagreement (e.g., Dan's comment), so we're looking for additional opinions. ------=_Part_20491922_1544569321.1410343158012 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: times new roman,new york,times,serif= ; font-size: 12pt; color: #000000"><div><br></div><hr id=3D"zwchr"><blockqu= ote style=3D"border-left:2px solid #1010FF;margin-left:5px;padding-left:5px= ;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-= family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Gianluca C= ecchi" <gianluca.cecchi@gmail.com><br><b>To: </b>"Sven Kieske" <s.= kieske@mittwald.de><br><b>Cc: </b>"Allon Mureinik" <amureini@redhat.c= om>, "users" <users@ovirt.org><br><b>Sent: </b>Wednesday, Septembe= r 10, 2014 10:57:27 AM<br><b>Subject: </b>Re: [ovirt-users] qemu-kvm-rhev o= n EL machines for oVirt 3.4.z ?<br><div><br></div><div dir=3D"ltr"><div cla= ss=3D"gmail_extra"><div class=3D"gmail_quote">On Wed, Sep 10, 2014 at 9:44 = AM, Sven Kieske <span dir=3D"ltr"><<a href=3D"mailto:s.kieske@mittwald.d= e" target=3D"_blank">s.kieske@mittwald.de</a>></span> wrote:<br><blockqu= ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid= th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l= eft:1ex"><span class=3D""><br> <br><div><br></div> > In the discussion on the patch [3], Dan raised the concern that 3.4.z = is a mature z-stream, and adding this dependency on <a href=3D"http://resou= rces.ovirt.org" target=3D"_blank">resources.ovirt.org</a>'s repos will effe= ctively blocks all vdsm updates for users which don't have these repos enab= led in their production environments.<br> <br> </span>I'm sorry but I don't understand this.<br></blockquote><div><br></di= v><div>Hello,</div><div>I directly put here what I see Dan wrote in the lin= k provided and that it seemed to me more a warning than a blocker.. (eventu= ally he may add further content...)</div><div><br></div><div>"</div><div><p= style=3D"margin-top:0px;margin-bottom:0px;padding-top:0.5em;padding-bottom= :0.5em;color:rgb(53,53,53);font-family:sans-serif">Patch Set 2:</p><p style= =3D"margin-top:0px;margin-bottom:0px;padding-top:0.5em;padding-bottom:0.5em= ;color:rgb(53,53,53);font-family:sans-serif">I'm not sure that this is a go= od idea for a mature z-stream. If someone has installed ovirt-3.4 without e= nabling the <a href=3D"http://resource.ovirt.org" target=3D"_blank">resourc= e.ovirt.org</a>'s repos, this patch effectively blocks all vdsm updates for= him.</p><p style=3D"margin-top:0px;margin-bottom:0px;padding-top:0.5em;pad= ding-bottom:0.5em;color:rgb(53,53,53);font-family:sans-serif">If we really = want this in ovirt-3.4.4, please explain why and warn about the downsides o= n <a href=3D"mailto:users@ovirt.org" target=3D"_blank">users@ovirt.org</a>.= </p></div><div>"</div><div><br></div><div>I don't completely understand too= ...</div><div>How could one have installed 3.4 without enabling <span= style=3D"color:rgb(53,53,53);font-family:sans-serif"><a href=3D"http://res= ource.ovirt.org" target=3D"_blank">resource.ovirt.org</a>'s repos?</span><b= r></div><div><span style=3D"color:rgb(53,53,53);font-family:sans-serif">Afa= ik the most of us who used EL 6 for their infra, then in soe way installed = the rhev qemu-kvm package or desired/asked to do so in some way...</span></= div><div><span style=3D"color:rgb(53,53,53);font-family:sans-serif"><br></s= pan></div><div><span style=3D"color:rgb(53,53,53);font-family:sans-serif">S= o I think that is this is clearly stated on release notes there should be n= o particular problem.</span></div><div><span style=3D"color:rgb(53,53,53);f= ont-family:sans-serif"><br></span></div><div><span style=3D"color:rgb(53,53= ,53);font-family:sans-serif">Gianluca</span></div></div></div></div> </blockquote><div>If we decide to move forward with this patch, we'll defin= itely provide qemu-kvm-rhev in the repo - the concern was indeed for users = who don't have this enabled.</div><div>Unlike 3.5, the 3.4.z repo doesn't s= eem to provide any "3rd parties" that can't be built from oVirt's sources -= so, theoretically, it can be installed without the repo enabled - and the = discussion here is whether this is an interesting usecase or not.<br></div>= <div><br></div><div>My personal tendency is to go forward (with a release n= ote, as suggested), but as noted, there is some disagreement (e.g., Dan's c= omment), so we're looking for additional opinions.</div></div></body></html=
------=_Part_20491922_1544569321.1410343158012--
On 10/09/14 11:59, Allon Mureinik wrote:
If we decide to move forward with this patch, we'll definitely provide qemu-kvm-rhev in the repo - the concern was indeed for users who don't have this enabled.
Unlike 3.5, the 3.4.z repo doesn't seem to provide any "3rd parties"
So we are talking about users who don't use the official recommended way to install ovirt (using the repo ) but instead download everything and install by hand? Are there any such people? Maybe they even do not use yum but rpm directly, or want to compile from source? On 10/09/14 11:59, Allon Mureinik wrote: that can't be built from oVirt's sources This is not true, here is an excerpt from ovirt-el-deps.repo from ovirt-release-11.2.0-1.noarch.rpm from http://resources.ovirt.org/pub/ovirt-3.4/rpm/el6/noarch/ [ovirt-epel] name=Extra Packages for Enterprise Linux 6 - $basearch #baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch failovermethod=priority enabled=1 includepkgs=epel-release,python-uinput,puppet,python-lockfile,python-cpopen,python-ordereddict,python-pthreading,python-inotify,python-argparse,novnc,python-ply,python-kitchen,python-daemon,python-websockify,livecd-tools,spice-html5,mom gpgcheck=1 [ovirt-jpackage-6.0-generic] name=JPackage 6.0, for generic mirrorlist=http://www.jpackage.org/mirrorlist.php?dist=generic&type=free&release=6.0 enabled=1 gpgcheck=1 includepkgs=dom4j [ovirt-glusterfs-epel] name=GlusterFS is a clustered file-system capable of scaling to several petabytes. baseurl=http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/epel-$rel... enabled=1 skip_if_unavailable=1 gpgcheck=0 [ovirt-glusterfs-noarch-epel] name=GlusterFS is a clustered file-system capable of scaling to several petabytes. baseurl=http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/epel-$rel... enabled=1 skip_if_unavailable=1 gpgcheck=0 So you already ship repo files for all necessary third party repos like gluster and epel in 3.4. HTH -- 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 Wed, Sep 10, 2014 at 01:11:02PM +0200, Sven Kieske wrote:
On 10/09/14 11:59, Allon Mureinik wrote:
If we decide to move forward with this patch, we'll definitely provide qemu-kvm-rhev in the repo - the concern was indeed for users who don't have this enabled.
So we are talking about users who don't use the official recommended way to install ovirt (using the repo ) but instead download everything and install by hand?
Are there any such people? Maybe they even do not use yum but rpm directly, or want to compile from source?
The purpose of this thread is to solicit objections to apossibly-distruptive change in a stable branch, not to disparage non-conventional deployments. If no one raises a serious objection, we can require qemu-kvm-rhev right after ovirt-3.4.4 is out.
On 11/09/14 14:02, Dan Kenigsberg wrote:
The purpose of this thread is to solicit objections to apossibly-distruptive change in a stable branch, not to disparage non-conventional deployments.
well you already did disparage non-conventional deployments in the past e.g. users using json over rest api in 3.3.z need to adjust stuff because during 3.4.z cycle it was communicated that the 3.3.z json api was not "officially" released at the time and therefore was altered in 3.4. (somehow it was forgotten to announce this during the 3.3. cycle..)
If no one raises a serious objection, we can require qemu-kvm-rhev right after ovirt-3.4.4 is out.
so this is really strange: for some stuff, you support or want to support deployments which where never supported (the install guides are quite verbose about how to install, and they all use the ovirt repos, none uses local install) and on the other hand, you break compatibility with a previous release when it was never documented that this feature was _not_ officially released. Again: How many deployments do you think would suffer from a new qemu package shipped by ovirt repo? This was also altered in the past, e.g. with epel, gluster and jpackage repo added during the releases. Furthermore there are regression bugs which sat there for a while until the release was not supported anymore, fortunately this bug was not found in the next release, so no one fixed it, e.g.: https://bugzilla.redhat.com/show_bug.cgi?id=1120267 To make this clear: I don't need qemu-kvm-rhev myself I just think the project needs to make a clear guideline what gets changed at what point in the release process and then follow this rules _always_ . I still have evidence (see above) that this is not always the case. So I hope you will strive for a more consistent release process (I know you do). The last document from Sandro regarding the new release process looks promising. I appreciate you took this topic to the mailing list and I hope my opinion doesn't sound to harsh. If there are errors above, please feel free to correct me. :) -- 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 11/09/2014 14:02, Dan Kenigsberg ha scritto:
On Wed, Sep 10, 2014 at 01:11:02PM +0200, Sven Kieske wrote:
On 10/09/14 11:59, Allon Mureinik wrote:
If we decide to move forward with this patch, we'll definitely provide qemu-kvm-rhev in the repo - the concern was indeed for users who don't have this enabled.
So we are talking about users who don't use the official recommended way to install ovirt (using the repo ) but instead download everything and install by hand?
Are there any such people? Maybe they even do not use yum but rpm directly, or want to compile from source?
The purpose of this thread is to solicit objections to apossibly-distruptive change in a stable branch, not to disparage non-conventional deployments.
If no one raises a serious objection, we can require qemu-kvm-rhev right after ovirt-3.4.4 is out.
3.4.4 RC1 and 3.4 niglthly snapshot already deliver qemu-kvm-rhev.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
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 (10)
-
Allon Mureinik -
Alon Bar-Lev -
Dan Kenigsberg -
Daniel Helgenberger -
Federico Simoncelli -
Gianluca Cecchi -
Itamar Heim -
Nir Soffer -
Sandro Bonazzola -
Sven Kieske