Re: Anything Like Solaris' Live Upgrade?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On 01/28/2013 06:54 PM, Tim Evans wrote:
> It creates one or more "alternate boot environment(s)," then newfs's it,

This is redundant on CentOS

> mounts it, copies the running system to it, then applies
> upgrades/patches to it.  It does not touch the running environment

not true, you have severe performance loss and no reliable way to 
measure the impact of what that changeset is going to bring in. Patching 
the running system, with a failback option is far better. Unless you 
dont trust the platform at all. Lack of a reasonable manageable and 
predictable packaging system can cause that lack of trust.

> (except to create a housekeeping database for the multiple boot
> environments).  The target boot environment is made bootable, and the

the idea of bootable on Linux is limited to the kernel and the initrd ( 
which even has a shell ). Unless you installed a kernel in the 
transactino set, there is no need to update grub, since your existing 
running boot components are still intact ( if not, you can measure and 
handle it ). If you do update the kernel, the setup will retain multiple 
copies and your last running kernel is always retained as an option to 
boot from next boot cycle

> grub configuration is updated to include the second bootable
> environment, and the /etc/fstab file on the second environment is
> modified to reflect the disks/LV's it uses.

Take a look at the yum lvm plugin, it already does most of this - with 
some assumptions on what its going to snapshot and how you want to 
handle that.

> The whole idea is not to touch the running system, apply changes to the
> alternate system, then boot to the alternate when change is done. Once
> the reboot to the new environment is done, you can further use LU to
> replace the un-upgraded/un-patched original environment with a copy of
> the new one.

This kind of highlights the issue here, you are attempting to look at 
this with too far a solaris process mindset. Most CentOS best-practises 
are driven towards keeping a running system up, by not breaking it or 
needing to do downtime efforts. Some packages due to their nature will 
enforce this, like glibc; but on the whole, its considered acceptable to 
patch live and keep going, with the understanding that there is a 
failover option / failback opton, rather than assume a running system 
must be taken down for a patch to be applied.

There are exceptions, but most of them are niche implementation driven 
ones, on the whole CentOS is built to be patched in place. Take a look 
at the yum lvm plugin on how you can fairly-easily implement the extra 
step you mentioned ( i.e tweak fstab to boot from a diff lv / uuid ).

- KB


_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux