[CentOS-virt] CentOS 6 Virt SIG Xen 4.6 packages available in centos-virt-xen-testing
Alvin Starr
alvin at netvel.net
Thu Jan 21 16:17:55 UTC 2016
My comment was targeted more at naming than support.
I appreciate that there are vanishingly few resources to throw at support.
I am glad to see any xen support for C7 and am thankful of all those who
are putting in time to make things happen.
I try to help out when I can but it is all too infrequently.
On 01/21/2016 10:29 AM, Johnny Hughes wrote:
> This is a community SIG .. and xenproject.org does NOT release XSAs for
> 4.2. The goal of Xen4centOS was to use an upstream LTS kernel and
> update those as required to stay on an LTS. Also to do every second
> point release of xen (ie, 4.2, 4.4, 4.6). All so we are longer term
> than upstream, BUT we have supported code from upstream.
>
> So, the goal is to use supported code for the longest amount of time the
> upsreams support them. For xenproject.org .. they support the two
> newest releases. For kernel.org, they do a new kernel LTS about every 2
> years.
>
> We don't have 5000 engineers to maintain community SIGs like they
> maintain the distro. We have to have supported code from upstream projects.
>
> On 01/21/2016 07:46 AM, Alvin Starr wrote:
>> Its my impression that as a general rule from RH once some software has
>> been released into a major release any further release of that software
>> does not change major version or fundamental features..
>>
>> For C6 I would argue Xen 4.2 should stay packaged as xen and Xen 4.4 be
>> packaged as xen44 ...
>> I do not believe that Xen has been released for C7 yet so what ever
>> package version is released should be xen and others should be xen4x.
>>
>> It provides consistency for those who expect it and upgrading for those
>> who need it.
>>
>> Looking at a C7 with epel added.
>> I can see python, python2 and python3.
>>
>> On the other hand If your picking xen up from
>> http://someplace.org/riskey-development/xen.repo then your getting what
>> you ask for.
>>
>>
>> On 01/21/2016 08:09 AM, President wrote:
>>> RE: [CentOS-virt] CentOS 6 Virt SIG Xen 4.6 packages available in
>>> centos-virt-xen-testing
>>>
>>> My .02 is to stay the course. As a server admin, I want to be able
>>> to type things like:
>>>
>>>
>>> yum upgrade php
>>>
>>> not
>>>
>>> yum upgrade php55-epel-rpmforge-fancy-package
>>>
>>>
>>> Having to remember all the idiosyncrasies of a system is what causes
>>> some type of major failure in the future whenever (1) you forget
>>> something or (2) someone else has to pick up the box to adminster.
>>>
>>>
>>>
>>> --
>>>
>>> Craig Thompson, President
>>>
>>> Caldwell Global Communications, Inc.
>>>
>>> +1 (423) 559-5465
>>>
>>> caldwellglobal.com
>>>
>>>
>>> -----Original message-----
>>> *From:* George Dunlap <dunlapg at umich.edu>
>>> *Sent:* Thursday 21st January 2016 7:32
>>> *To:* Discussion about the virtualization on CentOS
>>> <centos-virt at centos.org>
>>> *Subject:* Re: [CentOS-virt] CentOS 6 Virt SIG Xen 4.6 packages
>>> available in centos-virt-xen-testing
>>>
>>> On Thu, Jan 21, 2016 at 12:01 PM, Peter <peter at pajamian.dhs.org> wrote:
>>> > On 15/01/16 05:57, George Dunlap wrote:
>>> >> As mentioned yesterday, Xen 4.6 packages are now available for
>>> >> testing. These also include an update to libvirt 1.3.0, in line with
>>> >> what's available for CentOS 7. Please test, particularly the upgrade
>>> >> if you can, and report any problems here.
>>> >
>>> > Per conversation in IRC, Xen 4.6 no longer includes xend and therefore
>>> > no longer has the "xm" command. This is problematic for people who may
>>> > be using xm in various scripts on their host (such as home-brewed backup
>>> > scripts).
>>> >
>>> > I think it's a bad idea to break this functionality without warning by
>>> > allowing a simple "yum update" to remove it. You will take a lot of
>>> > people by surprise and cause such scripts to stop working, if people are
>>> > running yum cron the situation becomes even worse.
>>>
>>> Thanks, PJ, for your input.
>>>
>>> Just to be clear:
>>>
>>> 1. In the Xen 4.4 packages (first released October 2014), xend was
>>> disabled by default; so anyone using xend at the moment has already
>>> manually intervened to enable deprecated functionality
>>>
>>> 2. In 4.4, the first time xm was executed, it printed this warning:
>>> ---
>>> xend is deprecated and scheduled for removal. Please migrate to another
>>> toolstack ASAP.
>>>
>>> See http://wiki.xen.org/wiki/Choice_of_Toolstacks for information on
>>> other alternatives, including xl which is designed to be a drop in
>>> replacement for xm (http://wiki.xen.org/wiki/XL).
>>> ---
>>>
>>> 3. ...and on every subsequent invocation, it printed this warning:
>>> "WARNING: xend/xm is deprecated"
>>>
>>> I think this constitutes "warning" that the functionality was going to
>>> break at some point. :-)
>>>
>>> Also, in most cases "s/xm/xl/g;" Just Works; most people have reported
>>> that changing from xm -> xl was pretty painless. So this isn't like
>>> upgrading from Python 2 to Python 3 (or QT 4 to 5, or...).
>>>
>>> > I think that due to this lack of backwards compatibility with Xen 4.4
>>> > and earlier versions it would be a good idea to not force the upgrade on
>>> > people who are not wary of it. I propose that the new packages carry
>>> > the name "xen46" and they purposefully conflict with the old "xen"
>>> > packages. That will require people to take positive action to do the
>>> > upgrade and hence avoid breaking systems unintentionally.
>>>
>>> This would avoid breaking things for people still using xm, which
>>> certainly has some value. However it has some costs:
>>>
>>> * The packages between C6 and C7 will now be slightly different,
>>> increasing the maintenance burden. This is not only in the spec file,
>>> but also in all the associated scripting machinery for managing
>>> packages in the CBS and smoke-testing packages before pushing them
>>> publicly.
>>>
>>> * Instructions for installing Xen are now differend between C6 and C7,
>>> and slightly more complicated, as they have to explain about Xen 4.6
>>> vs alternatives.
>>>
>>> * Users who have heeded the warning and switched to xl will have to
>>> make an extra effort to switch to Xen 4.6. If they don't follow
>>> centos-virt, they may not notice that there's a new package to upgrade
>>> to.
>>>
>>> I'm a developer, not a server admin, so I can't gauge how important
>>> this issue is. Before making such a change, I'd like to hear opinions
>>> from other people in the community about how important (or not) it is
>>> to avoid breaking xm, given the ample warning (>1 year) users have
>>> had.
>>>
>>> On the other hand, explicitly moving to a "xen${VER}" (both for C6 and
>>> C7) would make it simpler for people to step up and maintain older
>>> versions in parallel if anybody wanted to do so.
>>>
>>> Thanks again, Peter, for bringing this up.
>>>
>>> Peace,
>>> -George
>>> _______________________________________________
>>> CentOS-virt mailing list
>>> CentOS-virt at centos.org
>>> https://lists.centos.org/mailman/listinfo/centos-virt
>>>
>>>
>>>
>>> _______________________________________________
>>> CentOS-virt mailing list
>>> CentOS-virt at centos.org
>>> https://lists.centos.org/mailman/listinfo/centos-virt
>>
>> --
>> Alvin Starr || voice: (905)513-7688
>> Netvel Inc. || Cell: (416)806-0133
>> alvin at netvel.net ||
>>
>>
>>
>> _______________________________________________
>> CentOS-virt mailing list
>> CentOS-virt at centos.org
>> https://lists.centos.org/mailman/listinfo/centos-virt
>>
>
>
>
> _______________________________________________
> CentOS-virt mailing list
> CentOS-virt at centos.org
> https://lists.centos.org/mailman/listinfo/centos-virt
--
Alvin Starr || voice: (905)513-7688
Netvel Inc. || Cell: (416)806-0133
alvin at netvel.net ||
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20160121/f9571490/attachment-0001.html>
More information about the CentOS-virt
mailing list