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@xxxxxxxxxx nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
