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

[Reindl Harald]

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"

> 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

and these capabilities are exactly what anaconda can NOT provide

>> 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

it does as explained above

> 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

if you have a identical clone of a whole machine you can
play around with the upgrade as often as needed (snapshots)
and can prepare the whole transition, no matter preparing
configurations or rebuild packages as needed

the production machines are done after this tests / prepares

usually it takes 1-2 days to prepare a fedora dist-upgrade
for our production servers and the real update takes 5 minutes
for each machine with a 100% clear step-for-step-list


>> a change which damages this capabilities has to be fixed
> 
> For the situation we're discussing, I'll take safety over 
> speed any time

read my explanation above

the way i rollout is much more safe as any anaconda update
because i can prepare every single package if it is needed
and our production servers NEVER access the feodra repos
directly

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 while my upgrade-szenario
worked from F7 to F15 on 20 machines without any single
problem and from 3 upgrades with anaconda on my workstation
2 failed to boot after that and the second failed one was
my last anaconda update (the one try with preupgrade did
also fail) while on the other side i made around 180
yum-dist-upgrades without troubles on production environment
and around 100 on test/development-VM's also without problems

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120126/53210295/attachment.sig>