[Federated-fs] Meeting Minutes: Conference Call on 3/28

[Manoj Naik]

Please respond if there are errors or if I missed anything.

Manoj Naik
IBM Almaden Research Center.

Minutes of Conference Call to discuss Federated Filesystem Requirements

Attendees:
Dan Ellard, Craig Everhart (NetApp)
Renu Tewari, Manoj Naik (IBM)
Andy Adamson, Peter Honeyman (CITI)
Rob Thurlow, Spencer Shepler (Sun)
Arun Jagatheesan (SDSU)

Peter asked what the scope is of a common authentication domain in 
assumption A4. The (limited) scope we're starting with is to assume a 
single organization (somebody called it "regional") instead of a global 
world-wide domain, where users have a "common" identify across the 
federation. Dan mentioned that this is typical in enterprise 
environments. Peter wondered if we were limiting the scope by not 
considering user mapping or translations across file servers. Arun said 
this was a issue faced by grid folks where different admin domains 
within a university (for example) don't talk to each other well. Dan 
said that the current proposal, while limited in scope by not addressing 
cross-domain user authentication, could be expanded if participants 
understood the issues of user translations well.

Arun said A1 limited most of the requirements of the grid folks by not 
allowing client-facing protocols to change. Currently, the proposal does 
not permit ordinary users to perform replication, etc. which means we 
would need add-ons to make that happen. Everybody seemed to agree that 
not requiring client protocols to change is a good thing. Rob asked if 
we should consider extending current standards (like fs_locations_info 
in NFSv4.1) to allow write operations (maybe in a later version) to 
address some of these issues.

Rob agreed with David Black's comment to the mailing list that the 
document should define the problem more crisply. We need to elaborate on 
how clients traverse the namespace.

W.r.t. A4, Andy proposed that all that is needed is an agreement between 
the "neighboring" admins that are involved in setting up junctions. 
Nothing special needs to be done for users who continue to traverse the 
namespace using their security attributes - which means they may only 
see parts of the namespace (that they have access to) which is fine. 
Servers can control access to the junctions just like they do today. 
Somebody asked if we need special privileges from the target servers to 
query junctions that point to them.

Arun asked how the FSN is different from the local "name" (presumable 
path or fsid). Dan explained that FSN was just a federation concept. So 
why is there a separate junction key? Because FSN is essentially a tuple 
of NSDB and junction key. What's the format of the FSN? Is it a URI or a 
string name? While the exact format of the FSN is not important for the 
requirements doc, the current thought is that the junction key could be 
a UUID (so there are no collisions), whereas the NSDB could just be a 
DNS name. David Black had commented earlier that DNS names do not 
express location of NSDB well, but Dan countered that this is the same 
problem regular clients face as well.

Andy asked if the communication between the servers and the NSDB is 
secure. The answer is yes and should be part of the requirements. Do the 
queries need to be secure also? Rob said maybe - mandatory to implement, 
but not mandatory to use. Use RPC_SECGSS?

Rob asked if the single admin entity on line 50 could be expanded to 
include delegated administration which most current environments use. Noted.

Arun asked if the proposal could address the requirements of users being 
able to build a logical namespace with individual files pointing to 
different servers. This would be difficult to do with current protocols.

A discussion of the examples section followed. Dan explained the 
bootstrapping problem of creating filesets before junction creation. 
Also, note that the FSN can be either specified by the server (when 
reused after recovery) or obtained from the NSDB.

Arun mentioned that the grid folks have some requirements for federation 
but most of the them clash with basic assumption A1 (not changing client 
protocols). Nevertheless, he'll post them to the list.

There will be a revision of the draft based on the comments/discussion 
and another call will follow in
about 1.5 weeks.