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@umich.edu Sent: Thursday 21st January 2016 7:32 To: Discussion about the virtualization on CentOS centos-virt@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@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@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
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@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
notyum 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@umich.edu *Sent:* Thursday 21st January 2016 7:32 *To:* Discussion about the virtualization on CentOS < centos-virt@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@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:
- 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
- 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).
- ...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@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
On Thu, Jan 21, 2016 at 1:28 PM, Phill Bandelow phill@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
On 01/21/2016 08:02 AM, George Dunlap wrote:
On Thu, Jan 21, 2016 at 1:28 PM, Phill Bandelow phill@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.
They started bringing this up before the 4.4 release .. that one had to move from xm to xl. They also gave instructions: ==================================================== from the wiki:
Xen-4.4 and libxl
Note: All versions of Xen before version 4.4 had xm and xend enabled by default. The xen-4.4.1 (and newer) rpms instead enable xl support and no longer use xend. Please see /MigratingToXl for details on how to migrate from em rpms older than 4.4.1 to the new version ====================================================
Here is the link to /MigratingToXl
https://wiki.centos.org/HowTos/Xen/Xen4QuickStart/MigratingToXl
So, I would say people need to migrate to xl anyway.
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.
Well, the problem with that is xenproject.org does not maintain their old releases forever either.
How long will they release patches to 4.4?
It is already listed as unsupported, with 4.5 and 4.6 the only supported versions.
They have been releasing 4.4 patches recently .. not sure how much longer that will happen. Once they stop putting out 4.4 patches for XSAs, then it becomes difficult as the things they release for 4.5/4.6 will not necessarily work on 4.4 or below.
George, do you know?
On Thu, Jan 21, 2016 at 1:28 PM, Phill Bandelow phill@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
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
notyum 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@umich.edu> *Sent:* Thursday 21st January 2016 7:32 *To:* Discussion about the virtualization on CentOS <centos-virt@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@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@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
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
notyum 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@umich.edu> *Sent:* Thursday 21st January 2016 7:32 *To:* Discussion about the virtualization on CentOS <centos-virt@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@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@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
-- Alvin Starr || voice: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 alvin@netvel.net ||
CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
On 01/21/2016 09: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.
So what does this mean ..
xenproject.org supports 4.6 and 4.5 right now. (last 2 releases).
When they release 4.7 then they will support 4.7 and 4.6 and drop support for 4.5 .. and we will keep 4.6 active.
When they release 4.8, they support 4.8 and 4.7 and drop support for 4.6. At this point we will release 4.8 as an upgrade to 4.6.
If we want to get XSA patches, that is what we have to do. And we certainly want to continue doing security patches.
The alternative is we need dedicated engineers to figure out older things differ from the supported versions and how to backport code. As you move further from the supported version this becomes harder and harder.
If there are people who want to do this .. and if we can be sure they will do it for the long term, then maybe and older long term support can be created .. however, it becomes harder to maintain as time goes on.
Xen Project 4.4.0 was released on March 10, 2014 .. so that is basically 2 years on a major version. That also corresponds to the LTS kernel time frame. That is the best we can do and maintain supported upstream code.
On Thu, Jan 21, 2016 at 3:39 PM, Johnny Hughes johnny@centos.org wrote:
On 01/21/2016 09: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.
So what does this mean ..
xenproject.org supports 4.6 and 4.5 right now. (last 2 releases).
This isn't exactly right.
Recent releases have 18 months of "support" (meaning, bug fixes are backported), and then another 18 months of "security backports", which means only XSAs are backported [1], regardless of when or how many releases have been made. It just happens that most releases recently have ended up taking about 9 months, which means at any given time you have 2 in 'active support'; but that's mostly a coincidence. :-)
So 4.4 won't be getting any more point releases, but it should continue to get XSAs through March 2017. (This table [2] has it ending in March 2016, but I'm pretty sure that's a mistake.)
-George
[1] http://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases
[2] http://wiki.xenproject.org/wiki/Xen_Project_Release_Features
On 01/21/2016 09:52 AM, George Dunlap wrote:
On Thu, Jan 21, 2016 at 3:39 PM, Johnny Hughes johnny@centos.org wrote:
On 01/21/2016 09: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.
So what does this mean ..
xenproject.org supports 4.6 and 4.5 right now. (last 2 releases).
This isn't exactly right.
Recent releases have 18 months of "support" (meaning, bug fixes are backported), and then another 18 months of "security backports", which means only XSAs are backported [1], regardless of when or how many releases have been made. It just happens that most releases recently have ended up taking about 9 months, which means at any given time you have 2 in 'active support'; but that's mostly a coincidence. :-)
Cool. I do know that our target goal was every second release.
So 4.4 won't be getting any more point releases, but it should continue to get XSAs through March 2017. (This table [2] has it ending in March 2016, but I'm pretty sure that's a mistake.)
I would be for maintaining releases as long as there are XSAs for them .. obviously as long as we have people to maintain them.
The 3.18.x LTS kernel has support until Jan 2017. Then we will pick one with the longest lifetime and shift.
-George
[1] http://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases
[2] http://wiki.xenproject.org/wiki/Xen_Project_Release_Features
Thanks, Johnny Hughes
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
notyum 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@umich.edu> *Sent:* Thursday 21st January 2016 7:32 *To:* Discussion about the virtualization on CentOS <centos-virt@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@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@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
-- Alvin Starr || voice: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 alvin@netvel.net ||
CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
On Thu, Jan 21, 2016 at 4:17 PM, Alvin Starr alvin@netvel.net wrote:
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.
Yes, that's the way I understood you. :-) It's an interesting model to consider; as I said earlier, making that the standard (either always having "xen44", "xen46", "xen48", or starting with "xen" and then major upgrades getting renames as you suggest) has certain advantages if we ever go the manpower to maintain two different versions.
-George
-
Alvin Starr -
George Dunlap -
Johnny Hughes -
Phill Bandelow -
President