[Federated-fs] Conf call notes from 6/25/2007

[Touretsky, Gregory]

>> * Need namespace awareness of data caching appliances...
>> 	The consensus was no.  Should be the other way around.  The
>> clients should communicate with the caching appliance as usual and
the
>> appliance navigates the namespace on their behalf.  In the current
>> reqts, it's possible that if a caching appliance makes a copy of an
>> entire fileset, it can inform the NSDB node responsible for that
fileset
>> that it has a copy, and other clients could find it there, but that's
>> not the usual mode of operation for these caches.  [If we've
understood
>> the idea, please guide us.]

But how clients would become aware of the existence of such caching
appliance? 
Let's say we have /nfs/dir/junctionA path, which should bring us to the
data located at filesetA. FilesetA belongs to cell ABC.com in the US,
and clients from the same network would get the data directly. Now, we
have clients in Bangalore that require access to the same data. To
optimize such access, we've deployed caching appliance (or even simply
replicated the data) to some fileset in Bangalore. I want the ability to
ensure clients in Bangalore first approach local copy (whether cached or
replicated) before trying to access the original fileset overseas.

>>* Support various FSLs for the same junction, based on switched
>>conditions.
>>	Consensus was no.  Sounds like it could be handy in some cases,
>> but overloading the namespace violates one of our core goals: two
>> observers of the same item in the namespace should see (disregarding
>> temporary inconsistencies) the same thing.
>> 	A secondary consideration is the difficulty in framing the
>> "conditions".  It seems like these could be open-ended.  Right now,
the
>> resolution is done completely by the server and the client is only
>> presented with the result.  If there are client-based conditions
driving
>> the resolution, then the protocol has an extra step -- the server
will
>> respond to a client accessing a junction with another query: "Dear
>> client, before I can show you the proper instance of the object you
just
>> requested, I have to ask you some questions about yourself."  This
makes
>> caching difficult (or impossible, if the answers aren't
deterministic)
>> especially for caching appliances that are trying to demultiplex
>> accesses from many clients.
>> 	If there was a fixed set of conditions, that could all be
>> determined once and for all at mount time (for example) then this
might
>> be tractable, but the general case seems very hard -- and if you
agree
>> with the first bullet, undesireable to solve anyway.
>> 	Again, if there's a compelling use case, let's hash it out.

Ideally, I'd like to eliminate automounter (whether autofs or am-utils)
from the environment, once we get federated-fs implementations. I'd
leave the completeness of all conditions to the administrators.
Conditional mountpoint resolution is very helpful in large environments,
which may require network separations due to security reasons or
geographical distances. See the US/Bangalore example above - conditional
mounts/redirections might be solution for that.