[160] in athena10
Re: Filsys Hesiod pointers in Athena 10
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Sun Apr 13 21:06:36 2008
Cc: athena10@mit.edu
Message-Id: <53351F47-B48E-4A82-9DFE-3FC1FCD5D7F3@mit.edu>
From: Jonathan Reed <jdreed@MIT.EDU>
To: Timothy G Abbott <tabbott@mit.edu>
In-Reply-To: <Pine.LNX.4.64L.0804131740230.12114@vinegar-pot.mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Sun, 13 Apr 2008 21:05:51 -0400
> This leaves us with a few options:
> 1) Implement fallback in our automounter
> 2) Implement priority resolution but not fallback in our automounter
> 3) Use the current implementations, and when convenient change all
> existing Hesiod entries using priority to only offer one option.
>
> I currently prefer (3) because it results in a simpler system with
> negligible loss in functionality, but don't have strong feelings on
> the matter and don't know how many filsys entries use priority today.
To aid in this decision, perhaps we could ask Ops to get us a list of:
a) The filsys entries whose mountpoint currently differs from the
locker name (ie: the oracle8 locker).
b) The filsys entries currently using priority resolution/fallback
OTHER than user lockers (which I don't think we have to care about,
since most of the people who have such lockers know how to deal by
hand).
Additionally, once we have list (a), it would be ideal to do a cursory
search of the MIT Community web space to see if any documentation
needs to be upgraded, should we choose to stop supporting lockers with
unusual mountpoints. I can think of two courses off the top of my
head that use the oracle{,8} locker, for example.
-Jon
