[OpenAFS-devel] DRAFT: New sysname standard

[Ted McCabe]

At 1:29 PM -0400 5/8/01, Derek Atkins wrote:
>This is already an issue today.  There are sites that use their own
>@sys values.  I've seen, for instance, i386_rh60.  They just need to

Yes, it is an issue today.  As I understand it, this example is due 
to the current set of possible @sys values not being sufficiently 
specific in definition nor broad enough in scope.  Thus the new 
proposed standard.

>have their workstation startup scripts run "fs sysname i386_rh60" and
>voila, they have a new, "non-standard" sysname.  Adding new sysnames
>do not, IMHO, make the problem any worse than it is today.

I agree, adding new sysnames, or using unconventional sysnames 
doesn't make the problem any worse.  Adding arbitrary new @variables, 
which is the suggestion I was responding to, does make things worse.

Also:
At 1:19 PM -0400 5/8/01, Jim Rees wrote:
>   Such a scheme for allowing dynamic allocation of additional/arbitrary
>   @variables seems to require a method of exporting your @variables and
>   mappings so that other cells can understand your filesystem.
>
>What do you mean by this?

First off, small correction.  After some more thought, I would change 
the word "cells" to "clients".  To elaborate further:

We are quickly approaching (if not already in) an environment whereby 
a significant number of AFS users administer their own machines.  The 
proposal that I am replying to would allow those users to define, and 
then use in their own part of the filespace, arbitrary @variables 
with arbitrary values.  Looked at from the POV of a systems 
administrator who wants easy, full control over my machines, this 
seems like a wonderful thing.

However, when I look at it from the POV of someone who considers how 
easy this might be for users to cope with, one thing jumps out at me 
as a big pain in the butt.  There is, a priori, *nothing* that gives 
me any clue how to interpret, for example @machine, were I to 
encounter it in a path and my particular client were not already 
aware of some interpretation thereof.

Granted the problem exists now with possible use of non-standard 
values for @sys, but that's still a much simpler and smaller 
translation problem.  The feature of arbitrary @variables seems to be 
very likely to make this translation problem extremely more 
difficult.  More difficult that is, unless we also provide a means 
for clients to somehow readily be made aware of another client's 
@variable mappings.

Right now at least the @sys interpretation, tho' technically free to 
be arbitrarily defined from client to client, is well-defined by 
convention.

>   Otherwise, there's nothing standard about it.
>
>Variable names and values would be standarized by convention only, just as
>they are today.

Yes, but at least we have a convention.  The proposal I am objecting 
to lacks any such convention.  I can imagine such a convention coming 
into being for specified @variables (which reminds of other issues, 
but issues that I see as eventually resolvable and not germane here). 
With arbitrary @variables coming into play, I can only imagine 
confusion as the result.  I'd welcome any method of establishing an 
@variable/value convention that could avoid said confusion while 
supporting arbitrary @variable usage.

    --Ted