[Federated-fs] fed-fs meeting minutes, 8/14

[Daniel Ellard]

A few clarifications below.

On Fri, Aug 15, 2008 at 10:20 AM, James Lentini <jlentini at netapp.com> wrote:
>
>
> Attendees
> ---------
>
> Renu Tewari (IBM/ARC)
> James Lentini (NetApp)
> Andy Adamson (NetApp)
> Theresa Lingutla-Raj (NetApp)
> Dan Ellard (BBN Technologies)
> Paul Lemahieu (EMC)
>
> Minutes
> -------
>
> + NSDB Protocol Document
>
>  Dan reviewed the changes he made to the NSDB protocol document.
>
>  The document describes the write protocol(s) used to interact with the
>  NSDB, but it does not cover an API for performing these operations. Dan
>  asked if it would be helpful to include a C API in the document.
>
>  Dan noted that the mechanism to answer questions an application is interested
>  in, such as "What are all the FSLs for this FSN?", are not covered in the
>  specification. The basic protocol operations operations are described, but
>  there is not an example showing how to put these together to answer higher
>  level question.

Actually, this is one of the queries that are covered in the spec.  But
there are many others that might be interesting that are not.  For example,
something like "give me a list of all the FSNs" is a trivial LDAP query, but
never spec'd explicitly.  A more complicated, nested query, is something
like "tell me all the FSN-to-FSL mappings, with all their annotations".  This
requires a nested query -- first, to find all the FSNs, and second to find
all the FSLs for each of them.  (there are other ways to do this, of course)

>  The consensus was that high level examples should be added to the document.
>  An example C API for accessing the NSDB could also be included, but would
>  not be mandatory.
>
>  Dan also noted that the LDAP attributes in section 8 were under specified. For
>  example, an attribute that is supposed to be a network address (either a FQDN,
>  IPv4 address, or IPv6 address) is only specified as a string type. This
>  would allow garbage entries to be placed in the NSDB.
>
>  There are two ways to approach this problem: (1) specify the types more
>  exactly in LDAP or (2) wrap the LDAP database with a layer that checks for
>  errors.

The third option is to push all the error checking out to the NSDB clients.
In this model, the client is responsible for verifying everything that comes
from the NSDB to make sure that it isn't garbage.

This is where we are now (except that the prototype doesn't do all that
much checking...).

>  James Lentini volunteered to investigate if (1) is possible.
>
>  We then discussed the requirements for unique UUIDs. It was noted that a
>  UUID can be generated by one or more administrative entities in the
>  federation. There is currently no mechanism to guarantee that a new UUID
>  being inserted into an NSDB is unique across the entire federation.
>
>  The difficulty of guaranteeing uniqueness was discussed. First, checking
>  the uniqueness of a UUID would require either synchronizing with all other
>  NSDBs or having a central authority. There is also the issue of what happens
>  when a FSN UUID is deleted when a junction still refers to it. If a new FSN
>  with the same UUID is created, the junction would point to the new FSN which
>  could be viewed as an error.
>
>  It was pointed out that an FSN is defined as a (NSDB name, UUID) pair. This
>  makes generating unique FSNs more tractable as the FSN's UUID only needs to
>  differ from the other FSN UUIDs on the given NSDB.
>
>  There is also a probabilistic argument that can be made for the uniqueness of
>  the UUID.
>
>  Dan suggested that we add text along these lines: "UUIDs must be unique in
>  order for correct system operation. We can approximate correct operation using
>  UUIDs generated using RFC4122.
>
>  We also discussed the benefits and disadvantages of wrapping the LDAP service,
>  option (2) above, further. Such a service could check for input errors, and
>  generate/validate UUIDs, and return the FedFS errors in section 7, rather
>  than LDAP errors (currently, there is no way to return the errors in section
>  7).
>
>  What protocol would be used to communicate with this service?
>
>  Web services protocols such as SOAP were discussed. ONC RPC was also
>  suggested as an obvious candidate because NFS and the FedFS admin protocol
>  already use it. It was noted that the protocol chosen would need to be
>  implemented on the file server, so choosing something reasonable for that
>  environment is important.
>
>  Andy pointed out that if there was a wrapper around the database, then the
>  protocol could be described, and the database backend could be changed.
>
>  Finally, Dan noted that the LDAP schema that had been present in previous
>  version of the document had been removed.  The schema is in an OpenLDAP
>  configuration file. The file is in the open source implementation that
>  NetApp is open sourcing.
>
>  Dan released NetApp's open source NSDB code last week. The code is available
>  on ftp.netapp.com, user anonymous, password is your email address, at
>  frm-ntap/opensource/snsdb-080806.tar.
>
>  The proposal is to keep the specific LDAP schema configuration file out of
>  the document. The document will have the intention, but not the specific
>  implementation.
>
> + Next Meeting
>
>  Next week we will cover the topics that we didn't get to this week:
>        - Push vs Pull for master root fileset replicas
>        - LDAP transactions
>        - How do other protocols, such as CIFS and DFS, make use of FedFS?
>        - Feedback on Dan's changes to NSDB Protocol document
>

-Dan