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

On Thu, Jan 21, 2016 at 7:17 PM, Sarah Newman srn@prgmr.com wrote:

On 01/21/2016 04:32 AM, George Dunlap wrote:

...

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.

My inclination is towards a naming scheme like xen46, xen48, etc + a meta package that always depends on the latest. It should be more obvious when there's a major upgrade, and those who can't afford a major upgrade can uninstall the meta package.

BTW, we had a discussion about this particular idea at the Virt SIG meeting, and KB said that different naming of packages like this can cause dependency problems. For example, a package depends on "xen-version >= $N" will fail because as far as rpm is concerned, you don't have package 'xen' installed at all.

Another idea is to keep separate repos, and then have "centos-release-xen-$VERSION", which would always point to $VERSION, and "centos-release-xen", which would always be the newest version. That might satisfy both types of people.

-George

On 22/01/16 01:32, George Dunlap wrote:

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

Xen4CentOS was first available in CentOS 6.4 with Xen 4.2, so we really need to look back that far. You may be right here, though, because Xen 4.2 was the first version of Xen that used xl by default. xl was still new at the time, though, and there were admins, especially ones who were migrating from a CentOS 5 based Xen, who would have preferred XM and were already using XM in other installs, so xm would have still seen widespread use at the time. That means that those boxes could very well still be using xm now.

2. In 4.4, the first time xm was executed, it printed this warning:

The warning was not in Xen 4.2 or 4.3. Considering that it is reasonable for someone to expect enterprise-like behavior from an enterprise distro, one would not assume that XEND would just disappear overnight.

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

There are some notable differences that can break compatibility in many cases:

1. xl does not support the "xl create foo" syntax, one must now use, "xl create /path/to/foo.cfg". This I can actually see breaking compatibility for a *lot* of people.

2. xl requires those that use the old xend networking setup to switch to a distro-based networking setup. This can be a serious undertaking for someone running a production machine with the easy possibility of breaking networking and requiring either OOB or physical access to the machine to fix. Therefore this in itself means that someone should be able to plan for the upgrade at a convenient time rather than having it sprung on them with a "yum update".

3. Config files no longer support embedded python.

...There are additional incompatibilities that could bite an unwary admin in the ass.

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.

These are certainly concerns, but there is precedence for doing it this way:

mysql (5.0), mysql51, mysql55 in EL5. bind (9.3), bind97 in EL5. ...etc

These are all cases of Red Hat offering newer versions without wishing to break older installs, and at least in the case of mysql, dropping support for the older version alltogether, but still doing it in a way that doesn't *force* the admin to upgrade and break their systems as a result.

I do believe that looking to what Red Hat has done in the past is appropriate when determining what action to take ourselves as people expect the same level of stability from CentOS, and consequenty Xen4CentOS.

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.

This is true, and I'd leave that choice up to you.

Peter

On Tue, Feb 2, 2016 at 2:47 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:

On 01/14/2016 06:57 PM, 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.

To upgrade:

yum update --enablerepo=centos-virt-xen-testing

To install from scratch:

• Install centos-release-xen from centos-extras

yum install centos-release-xen

• Update to get the new kernel:

yum update

• Install the Xen packages from the centos-virt-xen-testing repo:

yum install --enablerepo=centos-virt-xen-testing xen

Keep in mind that there is still a bug in the upstream CentOS new-kernel script which for some people consistently fails to add an "initird" line to the Xen boot stanza. Check /boot/grub/grub.conf; the Xen stanza should look something like this:

title CentOS (3.18.21-17.el6.x86_64) root (hd0,0) kernel /xen.gz dom0_mem=1024M,max:1024M cpuinfo com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all module /vmlinuz-3.18.21-17.el6.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=VolGroup/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet module /initramfs-3.18.21-17.el6.x86_64.img

-George _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt

Hello

I've attempted to upgrade today to xen 4.6 ( because of something which

seems to be a reincarnation of http://lists.xen.org/archives/html/xen-devel/2014-01/msg02259.html ) and I noticed that the new xen-runtime package tries to bring in a whole bunch of other packages:

Those kinds of dependencies are automatically generated by rpmbuild based on the linkages of the actual libraries.

I agree it would be nice to minimize the dependencies; but that would take someone sitting down and figuring out which features / components / libraries / whatever were causing the dependencies, and either disabling them or moving them to a separate package. I don't have time to do that at the moment; but I would be happy to help someone else do so, and review pull requests to the xen package repos at https://github.com/CentOS-virt7/xen.

-George