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
_______________________________________________
CentOS-virt mailing list
CentOS-virt@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos-virt
