System update spec proposal

[Mike C. Fletcher]

Christopher Blizzard wrote:
...
> So notes on the proposal:
>
> 1. There's a lot in here about vserver + updates and all of that is
> fine.  But we've been pretty careful in our proposals to point out that
> how you get to the bits to the box is different than how they are
> applied.  I don't see anything in here around vserver that couldn't use
> alex's system instead of rsync.  So there's no added value there.
>   
I would agree that vserver is largely orthogonal, with the assumption 
that we don't do a direct-to-file-system update (already discussed and 
agreed).

My understanding here is that Alex's system is currently point-to-point, 
but that we don't yet have any way to distribute it on the mesh?  That 
is, that we are looking at a research project to determine how to make 
it work in-the-field using some form of mesh-based discovery protocol 
that's going to try to optimise for connecting to local laptops.  I 
personally don't care which way we distribute, but I'm wary of having to 
have some mesh-network-level hacking implemented to provide discovery of 
an update server.

I'd be much more satisfied if there were something that could hook into 
some Jabber/Tubes/whatever distributed service that's already written 
and ready-to-go.  Of course, we wouldn't be able to do the 
nearest-neighbour update mechanism without the mesh topology 
information, but I'd be tempted to make that topology information a more 
general mechanism that any application could access, rather than making 
it a part of this particular daemon, and I'd be tempted to make that 
happen later rather than earlier.

I could have mis-read the comments and status on Alex's system, though.  
After all, it's just a custom per-file rsync operation, so it should be 
possible to update from almost any source, just as with rsync.  It is 
the auto-discovering and the like that sound rather low-level and 
fragile to me.  In other words, if we wanted to run s/rsync/Alex's 
system/ over Ivan's proposal, I'd be largely fine as long as the 
protocol is stable and reliable.  My concern is in trying to leap 
directly to the optimised laptop-to-laptop case with low-level network 
operations.
> I
> think that we need something that's actually designed to solve the
> problems at hand rather than seeing the hammer we have on the shelf and
> thinking that it's obviously the right solution.
>   
Fair enough AFAICS, as long as the protocol can be robust and stable 
within the time frame.
> Basically aside from the vserver bits, which no one has seen, I don't
> see a particular advantage to using rsync.  In fact, I see serious
> downsides since it misses some of the key critical advantages of using
> our own tool not the least of which is that we can make our tool do what
> we want and with rsync you're talking about changing the protocols.
>   
Hmm, interestingly I see "using our own tool" as a disadvantage, not a 
huge one, but a disadvantage nonetheless, in that we have more untested 
code on the system (and we already have a lot), and in this case, in a 
critical must-never-fail system.  For instance, what happens if the user 
is never connected to another XO or school server, but only connects to 
a (non-mesh) WiFi network?  Does the mesh-broadcast upgrade discovery 
protocol work in that case?

Enjoy,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com