On 10 February 2016 at 10:00, George Dunlap dunlapg@umich.edu wrote:

On Wed, Feb 10, 2016 at 4:36 PM, George Dunlap dunlapg@umich.edu wrote:

...

A couple of weeks ago I was just about to push an update of Xen 4.4 to Xen 4.6 to the Virt SIG repositories, and I suddenly got some push-back from the users, because Xen 4.6 has some fairly significant changes -- particularly the removal of the old toolstack daemon called xend. (xend had been disabled by default and had lots of messages warning about the upcoming deprecation, even in 4.4.)

It seems some users have the expectation that they should be able to run "yum update -y" on their servers on a regular basis, without having to worry about accidentally updating to a new major version that break things.

So one thing that was proposed was that we make separate packages somehow, such that users would have to actively request the newer version rather than getting it automatically. (This could be done either by having a package named xen46, or by having separate centos-release-xen-46 package that pointed to an entirely different repository.)

But of course, other users pushed back on that idea, saying they would always rather have the latest version Just Work, and didn't like the idea of having to manually keep track of what version was installed on any given system, or of actually finding out that there's a new package and what that new package name is.

KB and I chatted about it at the Virt SIG meeting, and decided that we should touch base with the other SIGs to have a consistent message.

As for my own opinion: I can see both sides of the story, and as a package maintainer I'd be willing to do either one.

But on the whole I tend to side with the "latest version" crowd. I think you should always be looking at what "yum update" gives you before installing it; even minor updates I can't guarantee are going to break things. And I'd rather the installation instructions be simple (don't have to mess around with version numbers), and I'd rather people not have to fish around for major updates (or run packages with unpatched security vulnerabilities because they didn't realize their packages were now obsolete).

What do other SIGs think?

Splitting the difference from a user point of view, here's another option:

• Have a separate repo for each major version
• Have the centos-release-xen-NN packages which always point to a specific repo
• Have the centos-release-xen package always point to the most recent repo

This is a tiny bit more infrastructure work, but makes it easier to test both minor releases and major releases; it also makes it easier for volunteers to step up and maintain older versions if they want.

If this is possible to do tooling wise then I would say this is your "best" bet. However, if this is too much of a headache, then I would stick with the latest push for multiple reasons:

1) People will assume you are still supporting/fixing 4.4 even when it is not happening. 2) Sites which need extra stability that this problem showed need to be aware this could have happened even in a 4.4.5 to 4.4.6 type update. [Too much software does this from Oracle, Microsoft to joes-open-source-email-reader] That is the nature of a lot of software which will bite you over and over again if you don't put in processes to mitigate that.

On Wed, Feb 10, 2016 at 5:49 PM, BC centoslistmail@gmail.com wrote:

On Wed, Feb 10, 2016 at 11:36 AM, George Dunlap dunlapg@umich.edu wrote:

...

As for my own opinion: I can see both sides of the story, and as a package maintainer I'd be willing to do either one.

Is 4.4 going to receive regular security fixes?

I am not planning on doing security fixes for Xen 4.4. I've made the invitation for others to do so, but so far nobody has stepped up.

Would a yum update to 4.6 work without downtime? By downtime I specifically mean the VMs that are currently running continue to run as expected and management of xen isn't broken, it just requires different tools.

No xen update will work without rebooting your machine, so 4.4->4.6 is not any different than 4.4.1 -> 4.4.2 in that regard.

If you're not running xend, then in theory a 4.4 -> 4.6 update should be just a matter of rebooting and starting up your VMs again. (Of course there may be bugs, but upstream Xen gets extensive testing.)

If you are running xend, but not using any xend-specific features or using xm in your scripts, then a 4.4 -> 4.6 update might just be a matter of rebooting and setting up the bridge via /etc/nework-scripts (since xend normally does the bridge set up for you), and using 'xl' instead of 'xm'. (They're designed to be compatible with a handful of explicit exceptions.)

If you're running xend and also using some of its special features, you may have to figure out how to do what you were doing before a different way.

But in the case of the last two, every time you've typed any command for the last 1.5 years, you've gotten a warning that says, "WARNING: xm/xend is deprecated."

If the first answer is yes, I prefer separate packages. If the second answer is no, I prefer separate packages. If the answers are no and yes respectively, then I would prefer yum update. If the answers are both no, then a simple yum update gets dicey. First you have different opinions on which method is the least surprise, but also you have potential PR backlash. Would the centos project as a whole and the sig in particular want to be seen as responsible for definite downtime (if 4.6 automatically comes via yum update) or for having known vulnerable packages? The latter can more easily be seen as the admin's responsibility, IMO.

I'm not sure what you mean, "The latter can more easily be seen as the admin's responsibility"?

Either way, I would suggest a wiki with a cheat sheet of common commands old vs. new.

Yep, the upstream Xen project has had that for a long time, and the Xen wiki pages on the CentOS project point to that page. :-)

-George