On 01/29/2013 02:03 PM, Tim Evans wrote:
> Thanks to everyone for their replies.
Excellent discussion, Tim. Thanks for bringing this up and coming back with
such good arguments.
Some of the objections I've seen on this thread:
1. LiveUpgrade takes too much CPU and disk space. Not if your system is sized
appropriately. Simple recovery procedures are worth considerable effort
and expense, which is why these features exist in Solaris. Redhat and
Fedora aren't quite there yet. But at least people are talking about it here.
2. YUM and various combinations of LVM are faster? The goal isn't to make the
overall implementation process faster, although it's been reasonable on
most major upgrades to Solaris. The important thing is to make the reboot
and resumption of services faster, including back-out. A major upgrade
will require a reboot in any case. If you're just doing a minor patch not
requiring changes to running processes, you can always use LiveUpgrade to
test it out without impacting your running system.
3. There's a Solaris mindset that makes people prefer LiveUpgrade? Not so.
AIX and some versions of SVR4 have had ABE support (Teradata comes to
mind). I think AIX lets you upgrade running processes in some cases. TMOS
with F5 has it. Networking gear often has the ability to upgrade a target
volume and rapidly boot off it with the ability to boot back. LiveUpgrade
in Solaris is just an implementation of offline upgrading/maintenance.
I see several techniques on this thread with potential to make offline
maintenance possible in the near future, or obtain a useful alternative
(pardon the pun).
It seems to me that if YUM, RHN, and RPM were designed to work in an alternate
root, we'd be 90% done with the project of implementing offline maintenance
for Redhat/Fedora. If yum upgrade --root=/a would work, GRUB and /etc/fstab
changes could readily be automated with existing tools.
I hope this discussion stays active in Linux circles.
Steve