Upgrades and image manifests

[Alexander Larsson]

On Fri, 2007-06-29 at 10:21 -0400, Dan Williams wrote:
> On Tue, 2007-06-19 at 14:39 +0200, Alexander Larsson wrote:
> The update daemon must provide a fair amount read-only status
> information before and during the update process to allow the GUI bits
> the flexibility to present that information to the user in the way it
> sees fit.

auto-updatinator (the mDNS background downloader) emits dbus signals
when there is a new version availible, and when it downloaded a new
blob. The actual applying of the update once its done downloading should
be triggered by something listening to that signal.

> Oh, and we should probably rate-limit or connection-limit the local HTTP
> server that's serving updates so we don't hammer one particular XO.
> This could mean putting an _advisory_ "try-me=true/false" flag in the
> mDNS advertisement that we switch depending on the current connection
> load.  The server would obviously still boot users if there were too
> many connections, but at least using the 'try-me' gives other laptops
> more information about whether they should try to connect right away, or
> try a different XO that may advertise the same blob.

Yeah. We currently only handle one file at a time in the local http
server. However, some rate limiting on that sounds fair. At the moment
we pick a new server to download each blob for randomly from the set of
availible servers that has the version we want.

> Have you thought about what information the mDNS record would advertise?
> In the best case, it's as large of a UDP packet as we can push out.  And
> since we can probably deal easily with packets up to the wireless MTU
> (which is something > 2000 bytes), there's more room than the
> traditional 512 byte UDP packet.  However, the space in the mDNS
> announcement is not unlimited, so I don't think we could put the entire
> blob list in there :)  There's certainly enough room to put a build
> number, HTTP server port number, manifest hash, etc.

At the moment we have image id, a list of image version ranges
availible, a base directory for the http uri, a hint that the server has
diffs and a "prio" hint which is unused atm.