bkbits.net downtime

bkbits.net downtime

[Larry McVoy]

Our T1 supplier, Global Crossing, is repairing a router at midnight 
Saturday PST.  Expected downtime is 3 hours but you never know.  If 
it turns out that they screw things up, we'll physically move bkbits.net
to a different location Sunday or Monday.  

Sync those trees...

Re: bkbits.net downtime

[Andreas Dilger]

On Jan 31, 2003  13:14 -0800, Larry McVoy wrote:
> Our T1 supplier, Global Crossing, is repairing a router at midnight 
> Saturday PST.  Expected downtime is 3 hours but you never know.  If 
> it turns out that they screw things up, we'll physically move bkbits.net
> to a different location Sunday or Monday.  

Actually, with BK it should be possible to have read only clones on
multiple servers, should it not?  Not that I'm saying BK should foot
the bill to do that, but having read-only clones of the primary kernel
trees would avoid most downtime.

I suppose it would be difficult for two servers to do a merge with
conflicts by themselves so multiple write clones are probably not super
desirable, but read-only clones should be pretty easy to set up and
keep up-to-date via "bk pull" (or even "bk push" triggered by a commit
script).

You could allow writing on a single read-only clone while the primary
is down and then update the primary when you move back, if that was an
issue, although I'm guessing that the DNS updates would take longer to
propagate than most outages.

I wonder if any of the kernel.org mirror sites would be interested in
hosting a clone of one or more BK repositories.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [Bitkeeper-announce] Re: bkbits.net downtime

[Chris Wedgwood]

On Fri, Jan 31, 2003 at 02:50:18PM -0700, Andreas Dilger wrote:

> Actually, with BK it should be possible to have read only clones on
> multiple servers, should it not?  Not that I'm saying BK should foot
> the bill to do that, but having read-only clones of the primary
> kernel trees would avoid most downtime.

At the risk of suggesting something insanely complex...

... assuming BK read-only copies do work, why not actually have 'bk
pull' for hosts which can serve RO copies of the trees?  You
could use SRV records to locate these transparently to what has been
deployed now (I'm not really a fan of rfc2782.txt but nonetheless it
exists and others are using it, so it's a 'standard' of sorts).

Presumably doing something like this means you could have many people
voluntarily providing RO trees for different projects and lessen the
load on the bitmover infrastructure...



  --cw

Re: [Bitkeeper-announce] Re: bkbits.net downtime

[Anders Gustafsson]

On Fri, Jan 31, 2003 at 02:46:27PM -0800, Chris Wedgwood wrote:

> ... assuming BK read-only copies do work, why not actually have 'bk
> pull' for hosts which can serve RO copies of the trees?  You
> could use SRV records to locate these transparently to what has been
> deployed now (I'm not really a fan of rfc2782.txt but nonetheless it
> exists and others are using it, so it's a 'standard' of sorts).

Or simply a domain-name with multiple A's with should work today
out-of-the-box.

-- 
Anders Gustafsson - andersg@0x63.nu - http://0x63.nu/

Re: [Bitkeeper-announce] Re: bkbits.net downtime

[Chris Wedgwood]

On Sat, Feb 01, 2003 at 12:06:38AM +0100, Anders Gustafsson wrote:

> Or simply a domain-name with multiple A's with should work today
> out-of-the-box.

How do you differentiate RO from RW hosts then?


  --cw

Re: [Bitkeeper-announce] Re: bkbits.net downtime

[Anders Gustafsson]

On Fri, Jan 31, 2003 at 03:07:57PM -0800, Chris Wedgwood wrote:
> > Or simply a domain-name with multiple A's with should work today
> > out-of-the-box.
> 
> How do you differentiate RO from RW hosts then?

You don't :) 

Except by giving the write-host a different name.

-- 
Anders Gustafsson - andersg@0x63.nu - http://0x63.nu/

Re: [Bitkeeper-announce] Re: bkbits.net downtime

[Andreas Dilger]

On Jan 31, 2003  14:46 -0800, Chris Wedgwood wrote:
> On Fri, Jan 31, 2003 at 02:50:18PM -0700, Andreas Dilger wrote:
> > Actually, with BK it should be possible to have read only clones on
> > multiple servers, should it not?  Not that I'm saying BK should foot
> > the bill to do that, but having read-only clones of the primary
> > kernel trees would avoid most downtime.
> 
> At the risk of suggesting something insanely complex...
> 
> ... assuming BK read-only copies do work, why not actually have 'bk
> pull' for hosts which can serve RO copies of the trees?  You
> could use SRV records to locate these transparently to what has been
> deployed now (I'm not really a fan of rfc2782.txt but nonetheless it
> exists and others are using it, so it's a 'standard' of sorts).
> 
> Presumably doing something like this means you could have many people
> voluntarily providing RO trees for different projects and lessen the
> load on the bitmover infrastructure...

That's exactly what I was suggesting, but not very clearly it seems.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: bkbits.net downtime

[Larry McVoy]

> Actually, with BK it should be possible to have read only clones on
> multiple servers, should it not?  

Oh, sure.  Even if we were down for a week, the trees which people care
about are almost certainly on their local disks so they could set up
servers all over the place make the data available if need be.

bkbits.net is a cache, it's not the authoritative source of anything.

> I wonder if any of the kernel.org mirror sites would be interested in
> hosting a clone of one or more BK repositories.

Eventually we'll have a version of the BKD that we've bullet proofed
enough that we'd encourage that.  For the time being we've encouraged
hosting at bkbits.net simply because (a) the infrastructure is there
and (b) if there are security problems then it's our mess not yours.

It's partially self interest: if kernel.org got compromised and it was
our fault then we'd get a black eye.  If bkbits got compromised we'd 
just fix it up quietly  (and, no, so far it has never been broken into
but that's probably because we're very careful about how we run things,
even if you got in via BKD you'd have no write permissions on anything
but tmp dirs).
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm