[Spacewalk-list] How to use Spacewalk to upgrade RHEL to higher version(s)?

[Fran Garcia]

On Fri, Nov 30, 2012 at 9:15 PM, Boyd, Robert
<Robert.Boyd at peoplefluent.com> wrote:
>
> Red Hat generally recommends against “upgrading” inplace from one major version to another even using the distribution disc much less this way.

Basically what they say is: "We're not going to support that. If it
breaks, you fix it".

Makes sense, as the support cost would skyrocket because it's
impossible to QA every posible scenario of upgrade. How many rebases
should they support? RHEL4 then upgraded to 5, then to 6? What if I
started in RHEL3, why can I upgrade to thel6?


> I wish they’d come up with a way that is smoother like other Unix based OSes like Tru64 Unix, Mac OS X and others that will help you upgrade in place.   Unfortunately that’s not the model with Linux.  One can hope and dream.   Having spent many years supporting OpenVMS, this was one of the nicer features of that OS from the very beginning.
>

HPUX and Solaris won't do in-place upgrades. Heck, even applying a
recommended patchset might totally wreck your Solaris installation,
that's why the coined the "break the mirror before patching"
procedure. Although we might have different definitions on what UNIX
is ;-)

OTOH some GNU/Linux distributions have supported in-place upgrade for
a long time: Debian and Fedora (and Ubuntu). But, except for desktop
users, that doesn't matter anymore.

> I’m really not sure why the engineering teams behind OS upgrades for linux think that their method of delete and reimage for major upgrades is an acceptable model.   It makes it more simple in terms of clearing the deck of any cruft that the previous release(s) might have included that need to go away instead of having to carefully craft scripts that will comb through and eject things that must disappear.   It however makes it a major pain for the system admin who must worry about reconstructing the server exactly as it was under the new OS.   I’m sure that kickstart mechanisms can make this much simpler, but it’s still a pain when you think about all the twisty little passages that make up a system configuration after the initial setup for special purpose servers.  Plus if you’ve installed custom packages that integrate into the directories under /etc and other system trees, you have to re-install them – you can’t just back them up and restore them unless you’re very clever.   Am I wrong?   Anyone have a different experience than this?   Tell me there’s a magic easy way and I’ll be happy to learn it.
>

We'll, unfortunately this isn't the 90s anymore. Things have been
accelerated and we don't have time any more to write 100 pages
documents describing every little detail on how a system is
configured. Even less time to create a document describing how to
rebuild a server that went through 3 different OS incarnations (manual
upgrade fixes included) and 5 generations of junior-type sysadmins
janitoring it.

What people expect now:

- Repeatable build procedures (PXE+Kickstart, check).
- Repeatable configuration and configuration versioning (custom RPMs +
Spacewalk configuration channels, check). If you have to tweak a minor
config for a server, do it inside Spacewalk! Self-documented and
repeatable!
- Infrastucture as a Code: self-documented and deployable systems and
applications in a recipe (Puppet/Chef/Capistrano/Ansible...).

I guess the greatest obstacle for this to succeed is educating
everyone involved in operating such systems. It's not very useful if
one person understands how Spacewalk/Whateverorchestrationtool work,
but nobody evolve their way of working and they still administer their
boxes by SSHing individually in each of them and doing random changes.

Regards