CentOS virt - Jan 2016 - 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.centos.org/pipermail/centos-virt/attachments/20160121/8674be32/attachment-0002.html>

Well when the last upgrade 4.2 > 4.4 went live and XM was disabled by
default it took many hosts down without warning. 4.4 > 4.6  may cause the
same issues. It's a dangerous upgrade for sure. Why can't 4.4 be LTS for
C6? as it's the last build with XM. Any XSA patches should not be hard to
backport. and maybe the optional xen4.6 for C6.

On 21 January 2016 at 13:09, President <president at caldwellglobal.com>
wrote:
> ?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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.centos.org/pipermail/centos-virt/attachments/20160121/ea104146/attachment-0002.html>

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              ||

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.centos.org/pipermail/centos-virt/attachments/20160121/f503ca3c/attachment-0002.html>

On Thu, Jan 21, 2016 at 1:28 PM, Phill Bandelow <phill at onapp.com>
wrote:
> Well when the last upgrade 4.2 > 4.4 went live and XM was disabled by
> default it took many hosts down without warning. 4.4 > 4.6  may cause
the
> same issues. It's a dangerous upgrade for sure. Why can't 4.4 be
LTS for C6?
> as it's the last build with XM. Any XSA patches should not be hard to
> backport. and maybe the optional xen4.6 for C6.
It's not a huge amount, but it is definitely time that I (and my
employer) would prefer to spend on other things.

As I've said elsewhere, this is a community project -- so if someone
wants to step up and maintain Xen 4.4 for CentOS 6, they are welcome.
I do agree that it shouldn't be a huge amount of work for someone to
pick this up, now that I've got the basic setup.  (And I'll definitely
still be around to help.)

If someone wanted to step up and maintain the 4.4 xen packages, I'd be
happy to hand that off, and just have xen46 for C6 and xen (v 4.6) for
C7.

 -George

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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos-virt/attachments/20160121/45ececca/attachment-0002.sig>

On Thu, Jan 21, 2016 at 1:28 PM, Phill Bandelow <phill at onapp.com>
wrote:
> Well when the last upgrade 4.2 > 4.4 went live and XM was disabled by
> default it took many hosts down without warning. 4.4 > 4.6  may cause
the
> same issues. It's a dangerous upgrade for sure. Why can't 4.4 be
LTS for C6?
> as it's the last build with XM. Any XSA patches should not be hard to
> backport. and maybe the optional xen4.6 for C6.
The Xen Project does large of testing of Xen before updates and
releases; and I do a basic amount of smoke-testing before sending an
update.  But I don't really have the resources or the ability to do
the kind of extensive testing which would allow me to recommend
automatically pulling updates without testing them first, nor do I
envision any SIG ever having that amount of resource.  If that's the
kind of support you want, you might want to consider paying for either
XenServer or SLES. :-)

 -George