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

[James Lentini]

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.
  
  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.

  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