Re: [nfsv4] Last call for NSDB Protocol for Federated Filesystems (Oct 4 - Oct 22nd)

[James Lentini <[e-mail]>]

On Wed, 3 Nov 2010, Robert Thurlow wrote:

> James Lentini wrote:
> 
> > There has been some discussion regarding the fedfsAnnotation LDAP attribute
> > defined in Section 4.2.1.12 that I wanted to record as part of this thread.
> > 
> > Chuck Lever discovered some ambiguities in the description of this
> > attribute's format. We discussed those issues during the FedFS concall on
> > 10/14. A revised description that attempts to eliminate those ambiguities is
> > included below.
> 
> I like the revised text without reservation.
> 
> > In the process of reviewing the revised text, Chuck, my co-authors, and I
> > have have been considering the utility of including this annotation
> > mechanism. Before LDAP was chosen for the NSDB protocol, this attribute was
> > created to allow private schema extensions. Given our use of LDAP, this
> > attribute may be obsolete.
> > 
> > Using LDAP there are other, arguably more natural, ways to allow for schema
> > extensions. For example, LDAP allows an entry's schema definition to be
> > extended by adding additional object types to the entry. In this approach,
> > the KEYs and VALUEs defined in Section 4.2.1.12 map to LDAP attribute types
> > and values respectively. This approach would allow implementers to define
> > their own annotation attributes, and would allow for standardizing such
> > attributes if there was interest.
> > 
> > Are there objections to removing the fedfsAnnotation attribute from the
> > schema and recommending that schema extensions be handled as described
> > above?
> 
> I wish to create a management application which uses the
> annotations fields as described in the current NSDB schema,
> and I think the use case really requires the current form
> of the specification, and not schema extensions.
> 
> The interesting-to-me use case is a kind of a back pointer -
> a way to track back from an FSL and/or FSN to the place in
> the namespace where this item is referenced.  I don't think
> this can every be truly reliable, but if you're taking a
> disk array down for planned maintenance and can send an
> outage warning saying that "the following filesystem paths
> are known to be affected", that could be useful at times.
> The unreliability is why this is not something I have tried
> to make a core part of the NSDB protocol.
> 
> So the goal is something like a "mountpath=/nfs4/my/path"
> piece of data.  The NSDB protocol as currently specified
> will let me just write this attribute whenever I manage a
> junction.
> 
> If I need to do this with LDAP schema extensions, someone
> must go through the non-standard LDAP management interface
> to get these bits added to the schema before I do my first
> bit of work in my management application.  That might be me,
> the vendor, trying to script something for all known LDAP
> implementations, or it might be my customer trying to read
> the fine manuals and do what I conceptually guide him to do.
> How many of us would ever do that as a vendor or a customer?
> Even if my environment is homogeneous, I may have to touch
> every LDAP server I use for FedFS, depending on what any
> replication solution supports.
> 
> In summary, I think I have something I would really like to
> implement which cannot be done properly without annotations
> as currently specified, so I would like them kept.

Clearly there is a use for this attribute. The next revision of 
draft-ietf-nfsv4-federated-fs-protocol will include this attribute 
with the revised definition of its format.

-james