UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?

[Nils Philippsen]

On Thu, 2012-01-26 at 14:19 +0100, Reindl Harald wrote:
> 
> Am 26.01.2012 14:08, schrieb Nils Philippsen:
> > For the sake of completeness:
> > 
> > On Thu, 2012-01-26 at 03:22 +0100, Reindl Harald wrote:
> >> after a yum upgrade you can verify that the most important
> >> things are fine BEFORE reboot (bootloader-config,
> >> package-cleanup --problems, ....), optimize/correct things
> >> you know are not fine after the upgrade (active services
> >> after transition to systemd as example) and then you reboot
> >> ONCE in a clean starting system instead a boot in the blue
> > 
> > ... as can be done on VC2 after updating with anaconda
> 
> while the system and services are running?
> show me how you will do this!

This not what I wrote.

> you are missing the point that "yum distro-sync" is running
> while the system is up and can be distributed after testing
> AUTOMATICALLY to 10,20,30,100 machines followed by a 30
> seconds reboot

I am well aware of the differences between doing an upgrade with
anaconda and doing it with yum in a live system. I've done enough of the
latter to at least shut down critical processes (e.g. MTA, database
server software) before doing a yum upgrade, because stuff tends to
hick-up if you pull the rug from underneath it (e.g. if files get moved
around, renamed, dynamically loaded modules are replaced by newer
versions with new API, data formats change, ...). What you described
sounds too non-deterministic for my taste. Granted, you reduce the
amount of planned downtime with this scheme, but you trade that in for a
heightened risk of unplanned downtime should stuff break in the process.
And testing only buys you a limited sense of security here.

> shutdown the VM, insert the ISO and boot anaconda takes much
> longer as the whole upgrade via yum - our machines needed
> between 4 and 6 minutes each server for the whole F14->F15
> upgrade, so in an hour you have all machines updated with
> nearly zero downtime

If all goes well. The move of pretty much every basic user space
building block from / to /usr has enough potentially disruptive
qualities that I'd rather have the patient not be the surgeon in this
round of open heart surgery. In less colorful words, anaconda is
self-sufficient, it brings everything it needs with it, i.e. its libc,
loader and so forth won't magically move to a different place so the
installer won't suddenly break because stuff it uses is removed, or in a
different place or format than expected. So if something breaks badly
during the upgrade I have a working shell and a small set of essential
tools that continue to work regardless, with which I can fix things.
This gives me enough warm fuzzy feelings that I'll happily spend the
little more planned downtime on it this time.

> a change which damages this capabilities has to be fixed

For the situation we're discussing, I'll take safety over speed any
time.

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils at redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011