Ivan's XO Field Upgrade Proposal

[Mike C. Fletcher]

C. Scott Ananian wrote:
...
> We use vserver copy-on-write to do the atomic upgrade.  There is a
> 'fake root' context (which i'll call /fakeroot here) which has all the
> files in the filesystem.  Activity containers & etc are created out of
> /fakeroot.  The upgrade process starts out with a copy-on-write clone
> of /fakeroot, which it rsyncs to get the new filesystem.  We then
> either:
>   a) save this new tree as /upgraded-root (or some such) and on reboot
> swap /fakeroot and /upgraded-root, or...
>   b) do some sort of pivot_root to swap these trees without rebooting.
>  This latter approach has more technical risk, but is still A Simple
> Matter Of Software and permits live upgrades.
>   
We should be planning to allow for the root file system to be 
potentially two or three layers deep with installed, but not yet fully 
tested/accepted upgrade overlays.  In general we will need a mechanism 
for allowing specification and construction of overlay structures.  We 
will need a UI element to allow the user to disable a given root overlay 
on boot (to roll back a failed/undesirable upgrade).

That is, our directory structure in most cases would look something like 
this:

    * coresystemsoftware/
          o .overlayplan
          o basesystem/
          o upgrade-2007-04-16-sometag/
          o upgrade-2007-05-18-nastystuff/
          o upgrade-2007-05-19-betterupdatestillbroken/
          o upgrade-2007-05-20-finallyfixed/

where .overlayplan might look like this (ignoring permissions, 
sub-systems such as /tmp,/proc,/dev and the like):

    [Layers]
    upgrade-2007-05-20-finallyfixed="Finally Fixed X Problem",ro
    upgrade-2007-05-19-betterupdatestillbroken="It'll work this time!"
    upgrade-2007-05-18-nastystuff="Oh, some problem found"
    basesystem="Core System Image",ro

and the UI would allow you to trigger changes to the file to prevent 
loading certain layers.

Key point being there that we probably want a more general mechanism 
than just "current and new".  We can allow for the intermediate updates 
to be skipped with rsync, as it will simply be "from where you are to 
where you want to go".  Policy can then decide when to compress out the 
un-activated intermediates and merge down to the final.

Anyway, just a thought,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com