[CentOS] Upgrading from CentOS 5.6 to 6.0

Tue Jul 26 05:07:36 UTC 2011
Mike Burger <mburger at bubbanfriends.org>

> On Tue, 26 Jul 2011, Mike Burger wrote:
>
>> If IBM can make this happen for their OS, and Red Hat certainly supports
>> such a process in the Fedora line of releases (including the ability to
>> list additional repositories for remote installation as part of the
>> process), they could certainly make it a supportable option for the RHEL
>> line.
>
> The upstream supports nothing as to Fedora, and indeed,
> members of that project regularly (and seem to gleefully)
> break forward compatability

I can not believe that the upstream does not guide/provide direction with
regard to the Fedora project, given that the Fedora project is still the
test bed for what eventually goes into the upstream's commercially
supported product.

> But you are missing the point -- WHY spend the engineering
> effort on trying to support such Major 'upgradeany's?  A new
> deployment takes mere minutes for a commercial shop, and by
> NOT supporting such explicitly, the upstream avoids much
> support and engineering load.

Quite simply, because the customer base, which is paying the upstream for
support, is requesting that such a process be supported.

Quite simply, as well, because the upstream is selling the customer on the
idea that their product is an enterprise level product.  Other enterprise
level *NIX providers support this process...the customer may reasonably
expect that this provider do the same.

Sure...it may take only a few minutes for a commercial shop to deploy an
OS, it takes that shop much more time to have to reinstall and reconfigure
the applications that run on those OS instances, test, cut over, etc.

Additionally, not every shop is running their entire Linux infrastructure
in a VM based environment. For those running physical systems, the
hardware may still be within their viable hardware lifecycle, but be in
need of a newer version of the OS.  Should the customer have to purchase
an additional physical system for each instance of their OS that must be
upgraded from one major release to the next?  Where would that leave the
customer, as far as having been sold on the cost effectiveness of their
Linux installs vs other commercial *NIX offerings?

How about those virtualized environments? Spinning up a new VM environment
to eventually replace the existing VM with a new OS instance may also
require the purchase of additional hardware, in an effort to support the
temporary resources needed to spin up, configure and test the new
instances prior to putting them into live use.

The cost of testing and then supporting live upgrade scenarios, born by
the upstream, would likely be less than the cost to the customer base in
potential hardware and manpower cycles, and would undoubtedly build the
upstream more good will from the customer base.

Consider, again, that the feature to perform an upgrade (and not via a
hidden upgradeany command line option) is available in the version of
Anaconda (the installation tool used by the upstream) that is in use for
Fedora intallations and upgrades, and that particular compilation of
Anaconda does include the ability to specify those third party
repositories from which one may have installed packages. It may be
compiled out of the binary that is in use by the upstream, but any of us
who have also used their test environment know that it's there, and are
more than aware that the upstream has and continues to disable certain
features of various included tools when shipping those tools in their
commercially supported distribution.

-- 
Mike Burger
http://www.bubbanfriends.org

Visit the Dog Pound II BBS
telnet://dogpound2.citadel.org or http://dogpound2.citadel.org

To be notified of updates to the web site, visit:

https://www.bubbanfriends.org/mailman/listinfo/site-update

or send a blank email message to:

site-update-subscribe at bubbanfriends.org