XO in-field upgrades

[Noah Kantrowitz]

C. Scott Ananian wrote:
> On 6/25/07, Noah Kantrowitz <kantrn at rpi.edu> wrote:
>> It is worth noting we are not using vhashify or any of the other util
>> scripts. The rainbow daemon sets up the chroot for each activity itself.
>> We are a bit non-standard in that we are doing process-level
>> containerization, instead of a more guest-OS system like many vserver
>> users (most?).
>
> So we're manually copying (or hard linking?) files into the chroot on
> every process activation?  Won't this wear down our flash?  (Or are
> all our chroots in RAM?)  How do/can we update the libraries/etc used
> by the process in the container?  Are services (like the proposed
> upgrade daemon) chrooted as well?  If so, how do upgraded files get
> out of the chroot?
>
> Could you give me a pointer to the design docs on rainbow/etc?
>  --scott
Design docs? We're still at the proof-of-concept phase really ;-). But
yes, each chroot needs to be generated on the fly when a new activity
starts (unless we do some funky magic with unionfs, which is probably
not a great idea). The load of a few directory hardlinks should be
minimal. Are we expecting to do online updating or will it be more of a
windows-style "shut it all down then patch"?

--Noah

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.laptop.org/pipermail/devel/attachments/20070625/65187e5d/attachment.sig>