[Federated-fs] FW: Notes from conference call

Everhart, Craig Craig.Everhart at netapp.com
Thu May 8 11:16:31 PDT 2008


Forgot to CC: the list.

-----Original Message-----
From: Everhart, Craig 
Sent: Wednesday, May 07, 2008 12:06 PM
To: Ellard, Daniel
Subject: RE: [Federated-fs] Notes from conference call

Hi, Dan.

Thanks for writing up this much from Paul, etc.

To your specific question, I'm available 5/8 and 5/15.  Will be in the
office with for the 5/15 call.

I want to be sure we're talking about the same discovery question: are
we trying to find an NSDB server or a file system to mount somewhere?
To me the base requirement is finding a file system to mount; any NSDB
servers can be found by the file server telling you where the NSDB
service is.  Finding a "local" NSDB service to act as a (shared) cache
is a nice touch but not semantically necessary.

There can easily be multiple namespaces that work by first locating a
file system:
	(a) the one I was describing where the user gives a domain name
	(b) some "local" one that the client, by convention, mounts on
"/idem" ("from the same place").
	(c) some "local" one that the clients as issued/administered by
organization XYZ mount under "/xyz".

We don't need a convention for (c); that's up to organization XYZ to
carry out in toto, including some pre-published configuration mechanism
for what to mount under "/xyz".

What I don't understand is what the user would ever expect to see under
the "/idem" notion here.

Now, there are other regimes that I suspect you may be talking about,
ones that look both for a local NSDB server and then its choice of FSNs
that might be published under standardized names:
	(a) the "local" NSDB server
		(a1) FSN "local", mounted at, say, "/local", or
		(a2) FSN "xyz" for organization XYZ--mounted where on
the client?  "/xyz"?

I understand a local NSDB server.  I also understand how an organization
might want to set up (a2), but I'd expect that it would be able to do
that itself, when it issued or configured its clients.  What doesn't
work is standardizing (a2)--some rule like "any unrecognized name issued
as a lookup under '/' is auto-mounted as an FSN under the machine root".
That sounds like an un-robust convention to me.

Which kind of question are we trying to answer with what you're calling
a "passive" lookup?

		Craig

> -----Original Message-----
> From: Ellard, Daniel
> Sent: Monday, May 05, 2008 2:51 PM
> To: federated-fs at sdsc.edu
> Subject: [Federated-fs] Notes from conference call
> 
> 
> - Due to connectathon and other events, it looks like the schedule for

> most of the participants is difficult for the next two weeks.  We may 
> need to postpone some of the calls.
> PLEASE let me know if you can
> attend:
> 
> 	Thursday 5/8
> 	Thursday 5/15
> 
> - Paul Lemahieu is going to write up his notes on a discovery protocol

> that combines the "active" and "passive" discovery modes.  (Active is 
> when a client knows it wants a particular server to be the root and 
> seeks for it, and passive is when a client isn't so fussy and instead 
> will accept a local root.) It's clear how to do "active" lookup with 
> SRV records.  It seems possible to do the local as well, with a local 
> DNS server modified to to answer queries for a generic name with local

> values.  For example, the name "nsdb" would always be resolved to a 
> local NSDB, and a local NSDB will always resolve junctionKey XXX 
> (where XXX is an agreed-upon constant
> UUID) to a local root.  There could even be a space of junctionKeys 
> (i.e., any with a given prefix) that resolve to different local roots,

> with different attributes, to give the client a choice.
> 
> - Dan is going to send around the schema that he has put together for 
> the LDAP-based NSDB.  He confesses nearly total ignorance of good LDAP

> schema design and would like some feedback on how to make things a 
> little more constrained (right now, most of the fields are simply 
> strings, so the NSDB has no way to confirm whether the values make any

> sense whatsoever).
> 
> - Renu is working on slides (coordinating with Theresa Raj) to show at

> Connectathon.  She will send them to the list later this week.  Rob 
> Thurlow is going to talk about replication-related issues at the 
> kickoff 11:30 on Monday 5/12, and there is going to be a fed-fs 
> presentation 2pm on Tuesday 5/13.
> 
> - Dan is looking for more comments on the most recent reqts draft.
> Please post them to the mailing list.
> 
> -Dan
> 


More information about the Federated-fs mailing list