XO in-field upgrades

[C. Scott Ananian]

On 6/25/07, Christopher Blizzard <blizzard at redhat.com> wrote:
> The broadcast just contains a product/version ID - doesn't have to
> include the entire update.  No more expensive than the presence stuff we
> have today.

You're misunderstanding me.  My concern is with waking machines up by
broadcasting this information.  We don't wake up on presence, but we
do want to wake up on (some, urgent) upgrades.

> I think that what Alex here can do it either way.  You could use the
> vserver copy on write stuff if you want to use the hammer of a

Again, you're misunderstanding me slightly.  Vserver has *very odd*
semantics for its copy-on-write and for writing inside containers.  We
need to sync up on that & come up with a plan, or we run the risk of
creating a useless tool.

Binary diffs are also bidirectional, FWIW.

> When you hear "complete blobs" can you describe what you mean?  I
> suspect that you're thinking of something different than what Alex has
> actually implemented.

Quoting from https://hosted.fedoraproject.org/projects/updatinator/ :
---
Each computer running Updatinator tracks a specific image id, and runs
a specific version of that image. Whenever it finds a manifest for a
later version of that image id (and that manifest is signed by the
right gpg key) that manifest and the required blobs for updating to it
is automatically downloaded. When the manifest and all required blobs
are downloaded Updatinator sends a dbus signal so that the system may
let the user apply the update (e.g. automatically, or by showing some
ui asking the user if he wants to update).
---

My next post will give some concrete #s justifing the use of binary diffs.
 --scott

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