System update spec proposal

[Christopher Blizzard]

On Tue, 2007-06-26 at 14:58 -0400, Ivan Krstić wrote:
> On Jun 26, 2007, at 2:21 PM, Christopher Blizzard wrote:.  Also
> > I would have appreciated it if you had given direct feedback to Alex
> > instead of just dropping your own proposal from space.  It's a crappy
> > thing to do.
> 
> Let's not make this about approach on a public mailing list, please.
> 
> > 1. There's a lot in here about vserver + updates and all of that is
> > fine.
> 
> There's terribly *little* in there about VServer. The COW mechanism  
> simply provides a convenient method to enforce containment of a  
> process that's about to go and do as it pleases to your OS files. If  
> you have a simpler way to do it, who cares about VServer?

Exactly.  I'm glad you agree that it doesn't matter which method we're
using.

> 
> >
> > 2. Because you have to use lots random
> > exceptions during its execution and once it starts you can't really
> > control what it does. problems at hand rather than seeing the  
> > hammer we have on the shelf and
> > thinking that it's obviously the right solution.
> 
> I'm sure there's a technical argument somewhere between the hand- 
> waving and the gratuitous hammer metaphors? The COW image gives rsync  
> its own little playground. If rsync then doesn't do *exactly* what  
> you expect it to do, to the bit, you've hit an error condition. And  
> rsync is pretty good about doing what it's told these days.

My technical argument is that rsync is a tool that's good at
synchronizing filesystems but you end up working around all of its
behaviors and like most script-driven tools, the errors that you can
gather from it are at best "it worked" or "it failed."  You can't really
use it to build a system that works pretty well because it's just that:
a giant hammer.

> 
> > 3. Still requires a server and doesn't let you
> > propagate changes out to servers as easily as his code does.
> 
> It requires a server because I think it's outrageous to consider  
> spending engineering time on inventing secure peer-to-peer OS  
> upgrades, never before done in a mainstream system, over a network  
> stack never before used in a mainstream system, two months before we  
> ship.

Pot.  Kettle.  Black.  Etc.

I would say that Alex has working code today and he's just waiting to
get to the next step.  And it seems to be based on a very simple design
that scales well.  So instead of yet another hack tower built on rsync
we can use something small, understood and contained.  And something
that fits the needs of the place in which it's going to be deployed.

> 
> > Basically aside from the vserver bits, which no one has seen, I don't
> > see a particular advantage to using rsync.
> 
> I'll ignore the meaningless VServer jab and point out that rsync  
> exists, is used in production all the time, is a known quantity, and  
> is a way to get this implemented *now*. We can play with Rube  
> Goldberg-style updates later.

It's not meaningless, for the record.  And the known quantities about
rsync are what I'm talking about here.  And the fact that the known
quantity of what Alex has today is that it's here and it works pretty
well should be informative as well.

--Chris