XO in-field upgrades

[Dan Williams]

On Mon, 2007-06-25 at 12:25 -0400, C. Scott Ananian wrote:
> 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?

No, stuffing actual update data into the mDNS TXT records is completely
impractical.  First off, you're limited by UDP packet size, and I'm sure
our updates are going to be larger than 512 bytes (even with UDP packet
sizes up to the MTU).

mDNS never carries actual _data_, it carries a service description about
the data.  The data itself is always out-of-band WRT mDNS.

Dan

> > 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
>