On 03/25/2014 11:23 AM, George Dunlap wrote: > On Thu, Mar 20, 2014 at 4:22 PM, Johnny Hughes <johnny@xxxxxxxxxx> wrote: >> 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? > So by "libvirt.org" code you mean "upstream libvirt", as opposed to > the EL version? Or are you trying to avoid the use of the word > "upstream" because EL is also "upstream" of CentOS? > > According to the libvirt.org download page: > > "These maintenance branches should only contain bug fixes, and no new > features, backported from the master branch, and are supported as long > as at least one downstream distribution expresses interest in a given > branch." > > The "maintenance release" pages don't have all releases, just a > handful of them. If we went with a libvirt.org tree, we should > probably coordinate with the libvirt project as to which release would > be best for us to standardize on. It seems likely that whatever > version of libvirt Ubuntu 14.04 is using will end up being a > maintenance release; choosing that one, if it's suitable, would mean > less maintenance work for libvirt upstream (resulting, hopefully, in > the tree being better maintained). > > Re compatibility, I thought one of the whole points of libvirt was to > allow this kind of backwards compatibility. We should obviously do > some basic smoke testing, but it would be a major fail for libvirt's > mission if an application compiled against 0.10 couldn't talk to a > libvirt running 1.2.3. > > Jim, do you know what the official policy is (if any) of different > versions of libvirt talking to each other? > > I don't know what consuming the EL libvirt would really be like, as I > don't have any experience with that. But overall it seems like the > best features would be if we consumed libvirt from libvirt.org, and > that security and bug fixes would be acceptable, particularly if we > shared a maintenance release with Ubuntu. If, as I expect, being a > different libvirt version doesn't cause compatibility issues, I think > we should probably just go with a libvirt.org tree. > > -George Yes, I meant a libvirt.org tree by upstream. I also think this would be the best option as well. I do see that CVE updates have been rolled into the maintenance branches even the 0.9.x version. So we can stablize on the same branch as Ubuntu 14.04 LTS ... that would be fine with me if it has what we want.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CentOS-virt mailing list CentOS-virt@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos-virt
