A different proposal for XO upgrade.

[Christopher Blizzard]

Just some comments on this thread.

It seems odd to try to optimize the bandwith on the actual local lan as
we have a decent amount of bandwith to work with.  The only use case
that I can come up with to support that is during unboxing and/or a mass
re-install.  And I don't think that we're ready to try and support that
with this first iteration.  It's a distribution method and probably
something that we can add after the fact.  (I know that some Red Hat
guys did something like this for a customer where an entire bank's set
of terminals could be completely re-imaged after a power failure in 20
seconds using a mutlicast-rsync setup.  I should see more about that.)
As long as the formats that we pick support something like this we
should be pretty safe for now.

The case where we do worry about bandwidth is the client <-> main
updates server setup.  That's where the bandwidth is likely very slow
and expensive and looking at using a diff-style system is worth the
investment given our install base.  I think Alex is looking into this
now.

I like the system that scott proposed for how often we should look at
updates and the idea of a "lead" to say "hey, I'm getting this update so
don't look."  (It sounds strangely familiar to an idea that I shared
with scott over lunch a month or so ago so of course I like it!) We also
might consider setting up other clients to start collecting the update
before it's completely finished downloading to start spreading around
the bandwidth over a longer period of time and making the entire process
more fault tolerant and bandwidth efficient on the local lan.  i.e.
someone else could pick up the rest of the update if the lead machine
vanishes.  Also, two machines might be able to get the update faster
than one, just due to latency over a lot of the links we're talking
about using.

--Chris