Re: [ovirt-devel] Update on QEMU Snapshot Package in CentOS

2014-06-24 Thread Itamar Heim

On 06/17/2014 09:56 PM, Brian Proffitt wrote:

All:

I spoke with KB at CentOS about maintaining the qemu package for the Virt SIG. 
He has expressed concerns that if oVirt curates the qemu package in order to 
have the snapshotting flag turned on, then there might arise a situation where 
each project within the SIG would be getting their own versions of qemu.


we just want the 'rhel version as is, compiled with an extra flag'.
if other groups the same srpm with other flags, i think should be ok 
(which is different than 'use a different srpm from head'.




To help mitigate against such an occurrence, KB suggested that oVirt take 
ownership of not the RHEL distro-specific version of qemu, but a more upstream 
version instead. Upon discussion with Douglas Landsgraf and Itamar, it seemed 
to make more sense to keep downloading from CentOS repo and rebuilding it with 
flag enabled and either sharing that with the SIG or inside our own oVirt 
repository.

Basically, KB's issue that if oVirt does wish to curate this package on behalf 
of the SIG, that we as a project would be willing to manage all requests from 
the rest of the SIG participants (such as the example he raised, which was his 
personal wish that the vdi and Microsoft vpc formats be turned on as well, so 
he can build Azure images more easily). If we were willing to take on such a 
responsibility for the SIG, then this would mitigate multiple versions of qemu 
appearing.

 From my side, I believe this is a reasonable expectation, given that we are 
going to get what we need within CentOS and still can be a responsible 
community player within the SIG.

I put the question to the developers: is this something we want to undertake, 
or should we simply maintain our version of qemu within an oVirt-specific 
repository?


I see two variants here:
1. RHEL proper SRPM, where the only change is how its built wrt 
flags/configuration allowing more than what RHEL comes with out of the 
box (would cover vpc format if just a flag).

will not cover special backports not going through rhel proper.

2. future/next/head/latest SRPM, based on an upstream qemu stable 
version rpm (or maybe the fedora virt-preview one is more likely).


one would be 'stable', the other 'updates-testing' or 'virt-preview'.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


Re: [ovirt-devel] Update on QEMU Snapshot Package in CentOS

2014-06-18 Thread Ewoud Kohl van Wijngaarden
On Tue, Jun 17, 2014 at 02:56:49PM -0400, Brian Proffitt wrote:
 All:
 
 I spoke with KB at CentOS about maintaining the qemu package for the Virt 
 SIG. He has expressed concerns that if oVirt curates the qemu package in 
 order to have the snapshotting flag turned on, then there might arise a 
 situation where each project within the SIG would be getting their own 
 versions of qemu. 
 
 To help mitigate against such an occurrence, KB suggested that oVirt take 
 ownership of not the RHEL distro-specific version of qemu, but a more 
 upstream version instead. Upon discussion with Douglas Landsgraf and Itamar, 
 it seemed to make more sense to keep downloading from CentOS repo and 
 rebuilding it with flag enabled and either sharing that with the SIG or 
 inside our own oVirt repository.  
 
 Basically, KB's issue that if oVirt does wish to curate this package on 
 behalf of the SIG, that we as a project would be willing to manage all 
 requests from the rest of the SIG participants (such as the example he 
 raised, which was his personal wish that the vdi and Microsoft vpc formats be 
 turned on as well, so he can build Azure images more easily). If we were 
 willing to take on such a responsibility for the SIG, then this would 
 mitigate multiple versions of qemu appearing.
 
 From my side, I believe this is a reasonable expectation, given that we are 
 going to get what we need within CentOS and still can be a responsible 
 community player within the SIG. 
 
 I put the question to the developers: is this something we want to undertake, 
 or should we simply maintain our version of qemu within an oVirt-specific 
 repository?

Personally I wonder why it's that important. With RHEL7 out and CentOS7
expected soonish, why not aim at supporting that. I'm sure that qemu is
new enough to support snapshots.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


Re: [ovirt-devel] Update on QEMU Snapshot Package in CentOS

2014-06-18 Thread Sven Kieske


Am 18.06.2014 11:03, schrieb Andrew Cathrow:
 We deliver a different QEMU in RHEL than is delivered in RHEV and RHEL-OSP.
 In RHEL 6 there's a different set of features at compile time.
 In RHEL 7.x you'll see us shipping different releases - eg. rebasing onto a 
 new QEMU version in RHEV/RHEL-OSP which is something that's not possible 
 within RHEL.

Well thanks for the response
but the only new information that you provide is
that you will rebase qemu in rhev which is not possible
in rhel 7.

but I was asking for some kind of reasoning _why_
that's not possible _and_ additionally would like
to point out that no rebasing at all is needed as it's
just recompiling with one flag added.

I begin to think this has something to do with marketing
as there is apparently no technical reason to do this.

Of course I know that you can not simply introduce a new
version in rhel6, according to your update policy and
your qa.

-- 
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
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Update on QEMU Snapshot Package in CentOS

2014-06-18 Thread Andrew Cathrow

On 06/18/2014 05:16 AM, Sven Kieske wrote:



Am 18.06.2014 11:03, schrieb Andrew Cathrow:

We deliver a different QEMU in RHEL than is delivered in RHEV and RHEL-OSP.
In RHEL 6 there's a different set of features at compile time.
In RHEL 7.x you'll see us shipping different releases - eg. rebasing onto a new 
QEMU version in RHEV/RHEL-OSP which is something that's not possible within 
RHEL.


Well thanks for the response
but the only new information that you provide is
that you will rebase qemu in rhev which is not possible
in rhel 7.

but I was asking for some kind of reasoning _why_
that's not possible _and_ additionally would like
to point out that no rebasing at all is needed as it's
just recompiling with one flag added.

I begin to think this has something to do with marketing
as there is apparently no technical reason to do this.


No it's about productization - how do we monetize investments that we 
make. That's something that we need to consider as we have literally 
thousands of engineers who have to be paid.




Of course I know that you can not simply introduce a new
version in rhel6, according to your update policy and
your qa.



___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


Re: [ovirt-devel] Update on QEMU Snapshot Package in CentOS

2014-06-18 Thread Andrew Cathrow

On 06/18/2014 05:24 AM, Sven Kieske wrote:

Thank you again for this clear response :)
I just wonder why this wasn't mentioned earlier, as I can perfectly
understand the reasoning.


It's certainly been discussed, but there are so many venues I lose track 
of what's been said where.


Aic



Am 18.06.2014 11:21, schrieb Andrew Cathrow:

No it's about productization - how do we monetize investments that we
make. That's something that we need to consider as we have literally
thousands of engineers who have to be paid.




___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel