[5192] in Moira
Re: Debathena and Moira
daemon@ATHENA.MIT.EDU (Garry Zacheiss)
Tue Sep 4 16:04:53 2007
Message-Id: <200709042004.l84K40uO017563@brad-majors.mit.edu>
To: Tim Abbott <tabbott@mit.edu>
cc: moiradev@mit.edu, debathena@mit.edu
In-Reply-To: Message from Tim Abbott <tabbott@MIT.EDU>
of "Sun, 02 Sep 2007 00:55:11 EDT." <Pine.LNX.4.64L.0708300427300.4096@coset.mit.edu>
Date: Tue, 04 Sep 2007 16:04:00 -0400
From: Garry Zacheiss <zacheiss@MIT.EDU>
>> On Athena, the Moira clients are all attachandrun scripts pointed to
>> binaries in AFS. I am told this is done in order to keep all copies
>> of Moira at the same version, so that protocol updates can happen.
That's historically been true. It's also the case that for some time,
the clients were evolving faster than releases were occuring, and it
made sense to maintain the software outside of the release.
This model has worked pretty well for us, and I do have some
reservations about giving it up. It's certainly my preference that we
continue to have control over all "production" Athena clients; for
better or for worse, moira isn't software we put much effort into
releasing or distributing, and that's unlikely to change in the near
future.
That said, the source is sitting around world-readable, and that's not
something we want to change either, so we can't really stop you from
distributing your own builds of clients.
Having stated my preference, I think the choice largely comes down to
whether you think the benefits are worth the costs. Of the two points
you raised, I think the com_err one is valid, although perhaps something
we could find a way to work around. I think concern about introducing
an AFS depdendency is a red herring. The moira locker and all the
volumes you need to traverse to reach it are replicated and
geographically distributed; an outage that prevents you from getting to
it has probably also made any environment that can meaningfully be
described as "Athena" effectively unuseable (and has a pretty good
chance of having taken the moira server with it).
I think the costs of managing your own builds are that you do need to
keep up with any changes we make to the client (noting that we're not
going to issue "releases" when things change).
A valid compromise I'd be willing to make is that given a build machine
(preferably with a distinct @sys/$ATHENA_SYS value not used by the
Athena release), I could maintain binaries in the moira locker for your
platform.
Garry
