10:32 a.m.
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).
10:44 a.m.
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
10:57 a.m.
On Wed, Sep 10, 2014 at 9:44 AM, Sven Kieske <s.kieske(a)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(a)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
12:59 p.m.
------=_Part_20491922_1544569321.1410343158012
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
----- Original Message -----
<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(a)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--
From: "Gianluca Cecchi" <gianluca.cecchi(a)gmail.com To: "Sven Kieske" <s.kieske(a)mittwald.de Cc: "Allon Mureinik" <amureini(a)redhat.com>,
"users" <users(a)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(a)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(a)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" &lt;gianluca.cecchi(a)gmail.com&gt;<br><b>To:
</b>"Sven Kieske" <s.=
kieske(a)mittwald.de&gt;<br><b>Cc: </b>"Allon Mureinik"
&lt;amureini(a)redhat.c=
om>, "users" &lt;users(a)ovirt.org&gt;<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(a)mittwald.de</a>&gt;</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
2:11 p.m.
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?
On 10/09/14 11:59, Allon Mureinik wrote:
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
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&arc...
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=f...
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.rep...
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.rep...
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
3:02 p.m.
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.
6:27 p.m.
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
9:19 a.m.
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(a)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
12:21 a.m.
New 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 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.
1:21 a.m.
New subject: [ovirt-devel] Building vdsm within Fedora
----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com>
To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>, devel(a)ovirt.org,
fsimonce(a)redhat.com, dougsland(a)redhat.com
Cc: "users" <users(a)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
9:20 a.m.
New subject: [ovirt-devel] Building vdsm within Fedora
Il 24/09/2014 00:21, Nir Soffer ha scritto:
----- Original Message -----
> From: "Dan Kenigsberg" <danken(a)redhat.com>
> To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>, devel(a)ovirt.org,
fsimonce(a)redhat.com, dougsland(a)redhat.com
> Cc: "users" <users(a)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
9:53 a.m.
New subject: Building vdsm within Fedora
----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com>
To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>, devel(a)ovirt.org,
fsimonce(a)redhat.com, dougsland(a)redhat.com
Cc: "Sven Kieske" <s.kieske(a)mittwald.de>, "users"
<users(a)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
10 a.m.
New subject: Building vdsm within Fedora
Il 24/09/2014 08:53, Federico Simoncelli ha scritto:
----- Original Message -----
> From: "Dan Kenigsberg" <danken(a)redhat.com>
> To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>, devel(a)ovirt.org,
fsimonce(a)redhat.com, dougsland(a)redhat.com
> Cc: "Sven Kieske" <s.kieske(a)mittwald.de>, "users"
<users(a)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
10:13 a.m.
New subject: Building vdsm within Fedora
----- Original Message -----
From: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
To: "Federico Simoncelli" <fsimonce(a)redhat.com>, "Dan
Kenigsberg" <danken(a)redhat.com>
Cc: devel(a)ovirt.org, dougsland(a)redhat.com, "Sven Kieske"
<s.kieske(a)mittwald.de>, "users" <users(a)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(a)redhat.com>
>> To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>, devel(a)ovirt.org,
>> fsimonce(a)redhat.com, dougsland(a)redhat.com
>> Cc: "Sven Kieske" <s.kieske(a)mittwald.de>, "users"
<users(a)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
10:44 a.m.
New subject: 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?
--
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
10:49 a.m.
New subject: Building vdsm within Fedora
----- Original Message -----
From: "Sven Kieske" <s.kieske(a)mittwald.de>
To: devel(a)ovirt.org, "users" <users(a)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
11:35 a.m.
New subject: [ovirt-devel] Building vdsm within Fedora
----- Original Message -----
From: "Sven Kieske" <s.kieske(a)mittwald.de>
To: devel(a)ovirt.org, "users" <users(a)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
12:01 p.m.
New subject: [ovirt-devel] Building vdsm within Fedora
Il 24/09/2014 10:35, Federico Simoncelli ha scritto:
----- Original Message -----
> From: "Sven Kieske" <s.kieske(a)mittwald.de>
> To: devel(a)ovirt.org, "users" <users(a)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/
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
12:07 p.m.
New subject: [ovirt-devel] Building vdsm within Fedora
----- Original Message -----
From: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
To: "Federico Simoncelli" <fsimonce(a)redhat.com>
Cc: devel(a)ovirt.org, "users" <users(a)ovirt.org>, "Sven Kieske"
<s.kieske(a)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(a)mittwald.de>
>> To: devel(a)ovirt.org, "users" <users(a)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/
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
11:57 a.m.
New subject: Building vdsm within Fedora
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
12:33 p.m.
New subject: Building vdsm within Fedora
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
5:40 p.m.
New subject: Building vdsm within Fedora
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
4:06 p.m.
New subject: [ovirt-devel] 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.
> 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.
7:21 p.m.
New subject: [ovirt-devel] Building vdsm within Fedora
----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com>
To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
Cc: crobinso(a)redhat.com, "users" <users(a)ovirt.org>, devel(a)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
12:42 p.m.
New subject: [ovirt-devel] Building vdsm within Fedora
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)
4:21 p.m.
New subject: [ovirt-devel] Building vdsm within Fedora
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)
12:42 p.m.
New subject: [ovirt-devel] Building vdsm within Fedora
----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com>
To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
Cc: crobinso(a)redhat.com, "users" <users(a)ovirt.org>, devel(a)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
4:24 p.m.
New subject: [ovirt-devel] Building vdsm within Fedora
On Fri, Sep 26, 2014 at 05:42:41AM -0400, Federico Simoncelli wrote:
----- Original Message -----
> From: "Dan Kenigsberg" <danken(a)redhat.com>
> To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
> Cc: crobinso(a)redhat.com, "users" <users(a)ovirt.org>, devel(a)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.
3710
days inactive
3726
days old
27 comments
10 participants
participants (10)
-
Allon Mureinik -
Alon Bar-Lev -
Dan Kenigsberg -
Daniel Helgenberger -
Federico Simoncelli -
Gianluca Cecchi -
Itamar Heim -
Nir Soffer -
Sandro Bonazzola -
Sven Kieske