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