[OpenAFS-devel] Soft mounts for /afs root

[Derrick J Brashear]

On 15 Jun 2001, Sam Hartman wrote:

> >>>>> "David" == David Thompson <thomas@cs.wisc.edu> writes:
> 
>     David> Derek Atkins wrote:
>     David> RO/RW mappings should be explicit, not based on names of
>     David> mount points.  Standards between sites vary too much.
> 
>     David> -- Dave Thompson <thomas@cs.wisc.edu>
> 
> When you make assertions like this, it is often useful if you back
> them up with arguments.  We're getting a lot of complexity introduced
> here to support things like local machine administrators that do not
> want arbitrary cells being discovered; selecting implicit vs explicit
> cells; selecting how to handle RW mount points.  I'm not convinced
> that requiring configuration for any of these options has been
> justified at any greater level than assertion.

Which seems to be the level that many admins or at least many site
policies operate at, so that's not entirely inappropriate, either. 
I for one don't feel bad for trying to create an environment at my site
which I feel provides the best user experience, based on my own experience
and feedback from those users.

Compile-time options would probably satisfy many people, but consider the
case of a vendor providing it. I suppose you could make the case for
"people who want something different need to recompile"

Since not all people who might care are actually providing input or
necessarily are aware their feedback is desired, the best we can do is
guess and try to provide a way to get their feedback. I for one am
unwilling to either:
-give up .andrew.cmu.edu in my /afs as a rw mount point
-have all other cells rw mount points available as /afs/.cell.name

The justification for the above is, respectively:
-we have configuration which expects /afs/.andrew.cmu.edu to exist
-I don't want to confuse things any more than needed

It's bad enough that we have some shortcuts in /afs, which means for
instance tab-completion of cs will produce a valid result instead of
something which makes it obvious that there are multiple possibilities. 
And it also encourages use of non-portable paths, but that's another
story.

Mind you, I'm saying this in my capacity only as the admin of my
site. For OpenAFS, until we have bits that do stuff the answer should be
considered but isn't strictly required. But it would be nice if some
consensus on the requirements for AFSDB could be had, so the OpenAFS 1.1
release could do it.

Please feel free to tear into me for being wrong about what's best for the
user experience as you may well be right.

-D