Subject: [nfsv4] FedFS Meeting Minutes, 12/11/2008

From: James Lentini <[email-masked]>
Date: Thu, 11 Dec 2008 15:06:30 -0500 (EST)

FedFS Meeting Minutes, 12/11/2008
---------------------------------

Attendees
---------

Dan Ellard (BBN)
Craig Everhart (NetApp)
James Lentini (NetApp)
Renu Tewari (IBM/ARC)
Robert Thurlow (Sun)

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 weeks meeting with this announcement.

+ Review revised R15 text

  Renu presented her revised text:

  ---
	R15: It SHOULD be possible for multiple fileservers in the
	federation to project a namespace with a common root.

	a. It SHOULD be possible to define a root fileset that is
		exported by one or more fileservers in the federation 
		as the top level of a namespace. [Corollary: There is 
		one root fileset per namespace and it is possible to
		support multiple namespaces per federation. ]

	b. It SHOULD be possible for a fileserver to locate an NSDB that
		stores the layout of a root fileset.

	c. It SHOULD be possible to access, store and update information
		related to a root fileset using the federation protocols.

	d. It SHOULD be possible to replicate a root fileset information
		across multiple repositories.

	e. If a root fileset if defined it SHOULD be possible, using the
		admin protocol, to enable a fileserver to export the root
		fileset for client access.
  ---

  What does it mean if there are no root file sets?  How does a client get started? 
  The client would be expected to know some entry point into the namespace. From 
  there, navigation of the namespace would be automatic.

  The word should permits an implementer to not bother with this. Robert would
  like to see these be mandatory to implement but not mandatory to deploy. He 
  did not want to place an onerous requirement on implementations. He felt that 
  some basic root fileset functionality could be required and more
  sophisticated features be left optional.
 
  We discussed this issue at some length. Craig noted that he would like to
  have an understanding of how this feature will be implemented before making 
  it a requirement.

  We agreed that a federation must provide a root (using DNS SRV for example) 
  but it would be optional if that root were replicated.

  The requirements do not specify how the root fileset is implemented. It could
  be stored in the NSDB or the file server.

  We discussed bullet (e) in detail. Dan noted that one of the original design
  goals was to allow unmodified NFSv4 filer servers to participate in the federation
  as leaves. He wondered if (e) worked against this goal. Robert observed that 
  there is no way to avoid server side work if the file server is returning a 
  FedFS-derived referral. If a node doesn't hand back a fedFS-derived referral,
  it does not need to be modified. Therefore (e) does not prohibit the use of
  unmodified NFSv4 servers as leaves of the namespace.

  We discussed the new bullet, (f), below. It was observed that if there are 
  replicas of the root fileset, the client may want to check when the server's
  root fileset was last updated. We noted that the fs_status attribute, 
  described in section 11.11 of NFSv4.1, can be used to determine this
  information.

  By the end of the meeting, we had this revised R15 text:
  ---

	R15: It MUST be possible for the federation to project a 
		namespace with a common root.

	a. It SHOULD be possible to define a root fileset that is
		exported by one or more fileservers in the federation 
		as the top level of a namespace. [Corollary: There is 
		one root fileset per namespace and it is possible to
		support multiple namespaces per federation. ]

	b. It SHOULD be possible for a fileserver to locate an NSDB that
		stores the layout of a root fileset.

	c. It SHOULD be possible to access, store and update information
		related to a root fileset using the federation protocols.

	d. It SHOULD be possible to replicate root fileset information
		across multiple repositories.

	e. If a root fileset is defined it SHOULD be possible to enable a
		file server to export that root fileset for client access.

	f. If a root fileset is defined it SHOULD be possible for multiple
		file servers to project a common root with defined consistency
		semantics.

  ---

+ Additional requirements draft comments

  Please send comments before 12/18. We would like to re-publish this document
  before the Holiday break.

Next week:
	- LDAP Discussion
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Robert Thurlow <[email-masked]>
Date: Tue, 16 Dec 2008 12:04:58 -0700

> 	- LDAP Discussion

Hi James,

I'd like to prepend something brief - we should talk about what
we want to present at Connectathon.  I'm currently listed as
owning a talk there, I'm not the ideal choice and we should
talk about content anyway.  I'd also like to find out who's
bringing FedFS bits to test, since I'm listed as the tech
coordinator for Replication/Migration.  I expect we needn't
take a full 10 minutes for this.

Thanks,
Rob T

---

From: James Lentini <[email-masked]>
Date: Tue, 16 Dec 2008 17:47:08 -0500 (EST)

> take a full 10 minutes for this.

Sounds good Robert. I will add this to the agenda.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4