On 03/19/2014 05:03 PM, George Dunlap wrote: > On Wed, Mar 19, 2014 at 7:18 PM, Johnny Hughes <johnny@xxxxxxxxxx> wrote: >> On 03/13/2014 12:04 PM, George Dunlap wrote: >>> On Thu, Mar 13, 2014 at 11:35 AM, Johnny Hughes <johnny@xxxxxxxxxx> wrote: >>>> On 03/12/2014 12:38 PM, Pasi Kärkkäinen wrote: >>>>> <snip> >>>>>> I get a forbidden on that SRPM ... do you have a copy somewhere? >>>>>> >>>>> Yep, here goes: http://pasik.reaktio.net/fedora/xen/xen-4.4.0-0.rc4.1.fc20.src.rpm >>>>> >>>>> -- Pasi >>>> OK, lets start making some decisions on what we want to try to use from >>>> a dependency perspective. >>>> >>>> What version of libvirt do we need with this? >>> [CC'ing Dario Faggioli and Jim Fehlig, who have been working on >>> libvirt on libxl] >>> >>> libxl is designed to be backwards compatible, so there are a number of >>> potential libvirt versions that should all work. >>> >>> What kinds of constraints are there from the CentOS side? i.e., why >>> not just use the most recent release? >> The only issue with that is then we have to keep moving up to the latest >> version all the time ... not very "enterprisey". If we can pick a >> version with long term maintenance, we should be able to keep it stable >> more easily. Maybe the EL7 version of libvirt with patches as necessary? > So, you asked "what version of libvirt do we need", but you still > haven't actually given me any reasonable constraints; without that, I > can't really answer the question. :-) > > Are there any versions of libvirt designated "maintenance" releases by > the community? Or is a release going to need to be "maintained" by > whomever wants to keep them going (as RH will do with whatever version > is in EL7)? Well, I am taking a look now and the version currently in RHEL7 Beta is libvirt-1.1.1-<ver>.el7 ... the latest in Fedora land is 1.2.2 and the CentOS-6 version is 0.10.2-<ver>.el6. I know that in the current xen4centos version of libvirt, we moved from the "EL6" 0.10.2 version to libvirt 0.10.2.<num> version to be able to leverage things written for that tree from other places and those new patches would not apply to the EL6 code because of backporting. There are still updates being added to the 0.10.2-maint tree on the libvirt.org site, so if we pick any version we should still get some updates ... though obviously changing to a newer version after we stabilize might cause issues. So picking a version we can use and sticking to it is a good idea. I guess if we pick any tree (like 1.1.1, 1.2.1, or 1.2.2) from the libvirt tree and stay in that branch we can stabilize and likely still get security coverage. If we pick the EL7 version we will get the RH backporting policy and maintain compatibility between CentOS-6 and CentOS-7 .. but there is much less code or documentation available other than just getting the packages from Red Hat, as they cherry pick things to pull in from all the libvirt trees and there is no real git tree available, etc. We can see what is in the SRPMS and create our own tree, but the code completely different from the libvirt.org trees. If we pick one of the libvirt trees from libvirt.org then we are likely going to be able to share work/code from other places that are leveraged against those trees ... if we pick the EL7 version we will have to develop our changes specifically to this project and the code will be very unique, but we will have tighter integration between CentOS-6 and CentOS-7. There is also the question of QEMU support and how to best marry that into libvirt, etc. I am just trying to get the discussion going so we can pick a version of libvirt that everyone can use for the CentOS SIGs, so that we don't have a "one off" in our branch. Looking at the ubuntu package search (http://packages.ubuntu.com/) for LTS (the latest I see currently being 12.04LTS), they seem to be using a 0.9.8 customized version of libvirt there. So, they do not seem to use the latest and greatest libvirt in their enterprise releases either. I am not a ubuntu numbering expert though, so I might be wrong :) What I am looking for is basically what concept do we want to use at this point ... EL code or libvirt.org code. It seems we picked libvirt.org code before because of the need to bring in code from other places ... but we tried to stay as close as possible to the CentOS-6 tree too so that people could, for example, use virt-manager from a CentOS workstation to connect to the Xen Dom0 sever and control it using libvirt. If we shift to libvirt-1.2.2, does that mean that we have to have people also update their non server machines they want to use to make connections for Dom0 control (or require a bunch of X on the Dom0 server to be able to use a GUI virt-manager via X, etc). Does this explain more of what I think we need to work out?
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CentOS-virt mailing list CentOS-virt@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos-virt
