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

[Nils Philippsen]

On Thu, 2012-01-26 at 15:49 +0100, Reindl Harald wrote:
> 
> Am 26.01.2012 15:07, schrieb 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 did - you wrote "as can be done"

Then, this is not what you wrote :-). I was referring to what I quoted
above: "after a yum upgrade you can verify that the most important
things are fine BEFORE reboot..., optimize/correct things... and then
you reboot..." Nowhere in the quoted text did you mention services that
keep running, which I grant is a huge difference between upgrades done
in yum and anaconda. Whether keeping services running while the world
changes around them is a good idea, however, I doubt it.

> > 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.
> 
> we build critical server packages usually on our own infrastructure
> and do version changes sepearted from the dist-upgrade as also
> the automatic restart on update is removed from all packages
> 
> as example we had MySQL 5.5 on F13
> 
> there is no limited sense of security
> each machine has a clone for backup-reasons
> this clones are updated first
> so after that i know the exactly behavior

In a strict sense, no, you don't. Assuming that your servers have users
that keep on using them while they're being upgraded (everything else is
pointless), their actions are a big unknown -- you can't know ahead of
time what they'll do during the machine is upgraded, and this may
trigger behavior in the running software which you did not test before.

> there is ALWAYS the internal build/repo-cache server between
> and that is why anaconda is unuseable and it would be
> a shame damage this capabilities

First, upgrading with yum never was fully supported[1], probably to
cater for situations like this one. Second, as you described it above it
seems you're not running Fedora, but your own forked off distribution (a
"Fedora Remix"[2] if you want to give it a nice-sounding moniker). You
could even forego UsrMove in your fork -- though that'd be a lot of
work: right now in F16/x86_64, there are 261 affected packages, so you
probably don't want to do that.

Anyway, I wonder what the drama is all about (and this goes to larger
parts of the audience)... I think a lot of this is based on
misunderstandings and conjecture: You already need to do certain
preparatory steps before doing a yum upgrade (e.g. install repository
GPG keys, disable and remove SELinux policy from F-13 to F-14). This
time you have additional steps[3] in order to run a script which moves
stuff about, preparing the system in a way which can't sanely be done in
RPM/YUM (re headless: AIUI this doesn't really need physical presence in
front of the box, and regardless: a serial console or similar is a good
thing to have). Then you do the upgrade as usual. What's the big deal
here again?

Nils

[1]: http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Upgrading_Fedora_using_yum_directly
[2]: https://fedoraproject.org/wiki/Remix
[3]: http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17
-- 
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