XO in-field upgrades

[C. Scott Ananian]

On 6/25/07, Christopher Blizzard <blizzard at redhat.com> wrote:
> Most of the stuff that Alex has done is (carefully) independent of any
> vserver or container discussion.  Specifically, the update system in
> question could be applied inside of a container as easy as it would be
> outside of the container.

I not sure I agree that the filesystem portion of the implementation
ought to be completely independent of the network portion.  I think
that networking desiderata are going to impact our choices among the
various upgrade schemes, and I'd prefer to have a high level design
for the whole thing before we get too attached to particular bits of
code.  As one example, since network reliability goes down quickly as
message size increases, it seems (to me, at least) that our upgrade
data messages should be made as small as possible.  It's not clear to
me that our current design minimizes upgrade transfer size.

> Re: broadcast, that's basically the same as any laptop exposing presence
> information.  For _transmission_ of an update, it's an interesting
> question as to whether or not to use a multicast update kind of thing.

Do laptops usually wake each other up to process presence information?
[Hopefully not.] Should they do so for urgent security upgrades?
[Hopefully.]

Here's a draft proposal:
We listen to multicast address  foo:bar:xxx:xxx:<n + 1> if we
currently have version # n installed on the machine.  Then we won't be
woken up by our friends announcing that they have version n like we
do, but we will be woken up as soon as someone gets version n+1.

On 6/25 Alex L wrote:
> mDNS *is* multicast. But the blobs won't be exposed over mDNS, that is
> far to much data for a protocol like that.

Really?  Do we know that?  What's a typical 0-day patch look like?
Have we tried to see how few bits it could be squashed into?

> Binary diffs seem much less useful. They enforce a specific base version
> that you have to have around, and they enforce the direction of upgrade.

This is *exactly* why we need to have the big picture view.  My
understanding is that we *are* expecting all laptops to have identical
bases, that the upgrade propagation rate and upgrade (in)frequency
will be sufficient that all laptops will be running the same version
of the software (save for a few stragglers who go on a long trip for a
few weeks), and that the vserver copy-on-write mechanism will be used
to perform rollback (so that we only need to worry about the forward
direction).

I'm not saying that my assumptions are correct.  But I feel that
deciding file formats before we've come to a big picture consensus may
be premature.

> If you can cheaply generate at runtime (on the client) a minimal diff
> between any two versions you can avoid storing unnecessary information,

Not sure exactly what you're getting at here: that we transfer
complete blobs over the network but store them on the XO as binary
diffs?  My working assumption is that network and storage costs on the
XO should be minimized as much as possible.  Transferring complete
blobs fails on these grounds.
  --scott

-- 
                         ( http://cscott.net/ )