[1327] in athena10
Re: [Debathena] #124: De-crustify the CellServDB
daemon@ATHENA.MIT.EDU (Evan Broder)
Fri Mar 6 17:08:15 2009
Message-ID: <49B19C95.2050609@mit.edu>
Date: Fri, 06 Mar 2009 16:58:45 -0500
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: Tom Fitzgerald <tfitz@mit.edu>
CC: Jonathon Weiss <jweiss@mit.edu>, debathena@mit.edu
In-Reply-To: <1236375193.5851.40.camel@sligo.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Tom Fitzgerald wrote:
>> Would you be open to trimming down the CellServDB to a shorter list of
>> cells than the full list maintained in grand.central.org? Since all
>> current Athena systems can use DNS these days (they can, right?), it
>> seems like having entries for cells that aren't essential to Athena is
>> just asking for them to become out of date.
>>
>
> I'd argue against this.
>
> Ops shouldn't be in a position of deciding which cells are
> essential to all Athena users. Admins of new cells shouldn't
> have to jump through two hoops to get them recognized on Athena.
> And users shouldn't be put in the position of figuring out why
> a computer installed from a public openafs package can get to a
> cell while an Athena system can't.
>
Whoa - that's not at all what I'm suggesting. All current Athena
releases (Solaris 9.4, Linux 9.4, and Debathena) will use AFSDB records
when a cell isn't in their CellServDB, so there are actually 0 hoops to
jump through.
> Granted, entries for cells that have AFSDB records are redundant
> on Athena systems, but they're also harmless and it's more work to
> remove them.
>
That's absolutely not true. There's a cost to maintaining our own CSDB -
it takes longer for us to receive updates when something changes,
because they have to go through jhutz and then through ops. Currently,
for example, it's the case that two of the three DB servers for
grand.central.org (including the one that we run) have changed IP
addresses since the last time the Athena CSDB was updated. If we didn't
have a CSDB entry for grand.central.org, since it's not an MIT cell (at
least sort of), there wouldn't be an issue here. (g.c.o may be a worse
example than others, but I think the point is still valid)
Having our own CSDB that's independent from the grand.central.org one
increases the time it takes to get updates into the field. It increases
the number of hoops that a cell admin has to jump through.
Instead, I think that we should not provide CSDB entries for most cells
that (a) aren't closely related to MIT and (b) don't have valid AFSDB
records. I'd be glad to try and construct such a CSDB based on the g.c.o
one and pass that to jhutz, if that makes it more likely for ops to
adopt it here.
- Evan
