Subject: [nfsv4] FedFS Meeting Minutes, 10/23/2008

From: James Lentini <[email-masked]>
Date: Fri, 24 Oct 2008 10:30:15 -0400 (EDT)

FedFS Meeting Minutes, 10/23/2008
---------------------------------

Attendees
---------

Paul Lemahieu (EMC)
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 action items

  [AI] James Lentini will research how to deprecate the old 
       individuals drafts.

  Complete. The drafts are now listed as replaced and a link to 
  the new working group versions is provided.

  [AI] Renu Tewari will draft root namespace requirements.

  Complete. See email to mailing list.

  [AI] Robert Thurlow volunteered to draft new text for the overview and R1.

  Complete. See email to mailing list.

  [AI] James Lentini will draft requirements for what access an administrative 
       tool will need for junctions.

  Open.

+ Continue Root Fileset Schema discussion

  Renu sent an email with the requirements. The email has showed up on the
  FedFs list but not the NFSv4 list yet.

  Here is the text of the draft:

  ----
  R15: It SHOULD be possible for 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 the
         namespace.
      b. It SHOULD be possible to create a root FSN for the root fileset.
      c. It SHOULD be possible to bind multiple  FSLs  to the root FSN.
      d. It SHOULD be possible for any fileserver to determine that a given
         FSN is a root  FSN.
      e. It SHOULD be possible to access, store and update information
         related to the root fileset  using the federation protocols.
      f. It SHOULD be possible to replicate the root fileset information
         across multiple NSDBs. [Note: Need to phrase this correctly]
      g. It SHOULD be possible for a fileserver to locate an NSDB that
         stores information on the root fileset.
      h. [Note: Can we allow multiple root filesets? ]
  ----

  Robert suggested the word "multiple" be added to the first line:

  "It SHOULD be possible for multiple fileservers in..."

  We discussed the utility of multiple root filesets. It was noted that in 
  the case of a corporate merger, allowing multiple root filesets would 
  be beneficial. 

  It was noted that if files were required to have a single unique path,
  multiple roots could pose a problem. However, we do not have this 
  requirement.

  We agreed to add a requirement to allow a federation to have multiple 
  namespaces and and that for each of these namespaces there should be 
  a way to locate the root.
  
  [AI] Robert Thurlow will write up a thought experiment on how multiple
       namespaces would work.

  We discussed the use of SHOULD versus MUST. The consensus was that it 
  SHOULD be possible for the federation to have a root namespace and, if 
  it does, the subsequent requirements would be MUSTs.

  We debated the need for item (f). We agreed that the terminology was 
  imprecise. Given that an NSDB can have multiple instances, the requirement 
  is for the root fileset information to be replicated across a single NSDBs 
  instances. The wording implies that the information will be replicated 
  across NSDBs. The consensus was that (f) should be removed.

  We also discussed (d). The motivation for this requirement is that the 
  file server needs to know that the FSN is a root file set so it can 
  simulate the contents of the root.

  We also discussed how the server administrator should be able turn on and 
  off root fileset access on the file server. One idea was for the existing 
  ONC RPC admin protocol to be able to do this. At a high level this makes 
  sense, but file servers have an existing interface for setting up exports.
  If there is another interface, there could be difficulty coordinating 
  between the two.

  Renu will redraft the text above and send it out for comments. 

+ Review of changes proposed for Overview and R1 

  In the overview, Robert wanted to separate the text into three things:
  (1) common practice today, (2) terminology, (3) the proposed solution 
  and why it is valuable.

  For R1, Robert removed the unnecessary text.

Next week:
- IETF NFSv4 working group engagement: proposed presentation at November meeting
- Conclude review of Robert's text for Overview and R1
- root fileset
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Robert Thurlow <[email-masked]>
Date: Tue, 28 Oct 2008 10:18:04 -0600

>   [AI] Robert Thurlow will write up a thought experiment on how multiple

I've written up the thought experiment (attached).  It's not in
the end terribly interesting.  Things work out well because we've
specified /nfs4/<domainname> as the first couple of path components.
The only things to pop out are that to support multiple domains,
implentations need to be prepared to look up non-default domains
at any time (instead of just at boot time), and users need to be
able to type in the domain part of the path name in order to
trigger the lookup of non-default domains.

Rob T
The merger scenario

High-level summary: because all paths include the DNS domain,
the only implication of multiple domains is that clients have
to be prepared to access alternate domains dynamically whenever
a new /nfs4/<newdomain> is accessed.

Currently, we specify the following:

  - the client place the root of the global namespace at /nfs4 [1]

  - the client uses its DNS domain to produce the next level
    of the namespace [1]

  - the client uses its DNS domain to look up a DNS SRV record
    to find NFS servers serving the root fileset [1]

  - the client accesses the root fileset servers to provide
    the entries in /nfs4/{domainname} [1]

  - a server serving the root fileset consults DNS to find the
    domain's NSDB [5]

  - a server serving the root fileset consults the NSDB to find
    the contents of the root fileset entries [5]

This all works fine when there is only one domain in play;
you have a new hire unpack a new computer, and it will run
software that figures out its default domain (via MDNS
broadcast, perhaps), and it will use the global namespace it
is intended to use.  A client could even be stupid and just
evaluate /nfs4/<defaultdomain> statically at boot time, and
all files would be reachable.

Does this still work when multiple domains (and thus NSDBs)
are introduced?  In particular, we've talked about the "merger
scenario" as being of interest.  Admins will probably expect
to spend some extra effort to make this work, but they need
it to be reasonable and effective.

Suppose we have Huge Federal Bank Inc. (hugebank.com) buying
Little Savings Bank Corp. (littlebank.com).  The day after
the underlying networks are merged, computer users in the
hugebank.com domain should be able to see new files belonging
to littlebank.com; in practice, this is gated by when their
DNS servers are updated to return information about both
domains.

hugebank.com users should see their native namespace as before,
but would probably need to enter /nfs4/littlebank.com to see
the newly-added files.  This implies that /nfs4/<domain> must
be dynamically parsed, not e.g. parsed once at boot time.
Users could be confused when they do not see contents under
/nfs4/littlebank.com already available because it is in another
domain, but ultimately all file paths are reachable.

The other new thing is that automatic domain discovery will
not always be easy; if employees from the separate divisions
are co-located on the same subnet, for example, it could
require manual per-client configuration to get their client
machines to be in the default domains they are might expect.
But if the lookups of new domains under /nfs4 do the right
thing dynamically, this should not be a real problem.  The
accessing of the user's home directory, if in NFS, might
happen to be enough to fill in that part of the namespace.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4