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