Subject: [nfsv4] FedFS Meeting Minutes, 6/17/2010

From: James Lentini <[email-masked]>
Date: Thu, 17 Jun 2010 17:41:48 -0400 (EDT)

FedFS Meeting Minutes, 6/17/2010
--------------------------------

Attendees
---------

Lawrence Anthony
Craig Everhart (NetApp)
Sorin Faibish (EMC)
Chuck Lever (Oracle)
Paul LeMahieu (EMC)
James Lentini (NetApp)
Trond Myklebust (NetApp)
Chris Stacey (EMC)
Robert Thurlow (Oracle)

Minutes
-------

+ IETF Note Well Agreement

  This is a reminder that our discussions are governed by the 
  IETF Note Well Agreement. See:

    http://www.ietf.org/NOTEWELL.html

  We will start each week's meeting with this announcement.

+ Bake-a-thon

  Rob, Chunk, and Trond reported on their work at the BAT.

  They have been testing referrals between Linux and Solaris,
  including NFSv4.1 referrals (fs_locations, not fs_locations_info).

  There are two NSDB's being tested:
  Chunk setup 389 DS as an NSDB.
  Rob setup OpenDS as an NSDB.

  Chuck and Rob each have implemented an Admin protocol client and server.

  Rob gave a demo on his FedFS tools this morning. 

  There were a few pieces of feedback on the Admin protocol:

  The use of multiple unions in the result of FEDFS_LOOKUP_FSN 
  proved awkward. The interior unions and structures were not tagged 
  correctly by rpcgen and this made accessing them difficult.
  The suggestion is to remove the FedFsResolveRes union and 
  replace it with a structure containing the FedFsUuid fslUuid<>
  array that is currently only defined in the default case.
  An array with zero elements would have the same 
  meaning as the FEDFS_RESOLVE_NONE case. There was also a 
  suggestion to add additional information for diagnostic 
  purposes. In particular the FSL's server and path. We 
  observed that it would be possible to obtain the server 
  and path using NFSv4, but this would require the Admin 
  client to also act as an NFSv4 client. This seemed awkward. 
  We decided to add FSL and NFS FSL XDR types and return an 
  FSL here.

  Another suggestion was to define an explicit fileserver 
  cache flush operation. This operation would have a 
  return codes to indicated success, no cache, or
  that the Admin server does not control of the fileserver's 
  cache (In some designs, the the Admin server will not 
  know the state of the NFS server's cache).

  We discussed the different reasons an Admin would 
  want to explicitly manage a fileserver's cache.

  A fileserver is allowed to cache the results of an LDAP 
  query for an FSL object's TTL. This is 
  analogous to the DNS. The Admin protocol allows an 
  administrator to flush a cache entry before 
  this TTL expires. Trond observed that this explicit 
  flush mechanism was only useful for those servers 
  the administrator was aware of. In a federation, 
  the administrator is not expected to be aware of 
  all fileservers that may need to be updated. Trond
  was concerned that multiple mechanisms (TTLs and 
  an explicit flush procedure) with the same goal 
  would cause confusion.

  There were some additional topics that we did 
  not have time to discuss in detail:

  What should the behavior be in the case of an 
  NSDB referral. How does this interact with 
  security (TLS)?

  In addition to an anonymous LDAP bind, should 
  there be a mechanism to communicate a specific 
  DN to the fileserver?

+ Meeting Schedule

  We will cancel the July 1 meeting and meet on July 8 instead.

  After the July 8 meeting, will will resume our once-every-two weeks 
  meeting schedule and meet on July 22.