[nfsv4] [FedFS] Meeting Minutes, 11/19/2009

[James Lentini <[e-mail]>]

FedFS Meeting Minutes, 11/19/2009
---------------------------------

Attendees
---------

Sorin Faibish (EMC)
Paul LeMahieu (EMC)
James Lentini (NetApp)
Trond Myklebust (NetApp)
Renu Tewari (IBM)
Robert Thurlow (Sun)
Chris Stacey (EMC)

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.

+ Review Action Items

  - Chris Stacey will write up example use cases for 
    a statistics command.

    Chris sent an email describing what types of errors the system can 
    generate when it is unable to resolve a junction in an NSDB. Paul 
    had some ideas about a tool that would walk the namespace to find 
    problem. Chris has been thinking about customer support tools that 
    would allow the system to proactively indicate errors. The tool Chris 
    envisioned is one that would poll a fileserver and discover it was 
    having problems with any parts of the namespace. It would be like a 
    traffic light and report red/yellow/green for a fileserver. Green 
    all good. Yellow, would be unable to contact some part of the 
    federation. Red would be unable to contact anyone. The tool 
    would then allow the user to drill down and get more information 
    about yellow and red conditions. 

    This gets back to the idea of whether the fileserver should maintain 
    statistics about what errors have occurred. If there are 15 different 
    implementations each with its own way of record these statistics, 
    then it is impossible to build a generic tool.

    James suggested that the problem domain be kept within the scope of 
    the namespace. The reporting capabilities would need to be significantly 
    more complicated if they are to report unrelated errors, such as disk 
    errors.

    Chris agreed that we didn't want this bleed into other areas. He suggested
    that there could be another catch all case for unrelated problem reporting.

    Rob stated that FedFs only errors seemed reasonable. Other errors are
    outside the scope.

    Paul asked if we have enough error return values that a client tool 
    can diagnose how where the error occurred.

    James reviewed the error codes added in the updated Admin draft.

    Trond noted that there are other errors on the client in handling a
     referral beyond those that the server might encounter.

    Trond also noted that there referral can be perfectly valid but the
     fileserver that the referral points to has just failed.

    Trond noted that v4.1 has variable substitution in paths, a tool that 
    walks all possible paths is difficult. Walking a specific path is 
    the only real option.

    Paul indicated that he wanted to build a tool that walked a specific path
    and that he believed we have the required primitives with NFSv4 and the 
    Admin protocol to build such a tool. He is happy with what we have to 
    build such a tool.

    For the tool Chris envisioned, there are additional capabilities
    necessary. Chris indicated that keeping counters wasn't as important 
    as indicating that an error had occurred.

    Rob suggested that an SNMP MIB might be more appropriate for this 
    purpose and that including other errors would make sense there.

    Chris indicated that an SNMP MIB would be a good solution. 

    Trond noted that in a federation with multiple fileserver being 
    able to interrogate other fileservers would be useful.

    Rob said that there had been discussion about SNMP MIBs for 
    NFSv4 servers but nothing for sometime. There were no writeups.

    There was consensus that an SNMP MIB was a good option.

    [AI] Chris Stacey will writeup a description of an SNMP MIB.

  - James Lentini add malformed response error code, string field to 
    response, generic resolve error code, and make resolve a 
    ternary value.

    Complete.

  - James Lentini to discuss TA management with Nico

    Complete.

+ Discuss Update to FEDFS_LOOKUP_FSN procedure

  The FEDFS_LOOKUP_FSN definition was updated with 
  additional error values, including an option for 
  communicating LDAP error values back to the administrator, 
  a malformed response error value (FEDFS_ERR_NSDB_RESPONSE) 
  and a generic resolution error (FEDFS_ERR_NSDB_FAULT). 
  The resolution options include no resolution, cached, 
  and NSDB.

  The updated draft is here:

  http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-admin-03bis.txt

  and a diff against the previous draft is here:

  http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-admin-rfcdiff.html

  There were no comments or suggestions on this topic.

  The changes above will be included in the next draft update.

+ IETF WG Meeting Feedback

  Trond summarized the NFSv4 WG meeting last week in Hiroshima.

  The notes for the meeting will be published soon. We were 
  interested in feedback on FedFS and any related topics.

  The meeting started with a discussion of the status of the 
  NFSv4.1 document set. Eisler's goal is to publish it by the 
  end of the year.

  The next topic was FedFS. Trond had a question about how the 
  admin client and fileserver authenticate each other. Mike 
  answered it at the meeting. Mike indicated that he was in 
  favor of the NFS path format.

  NFSv4 Multi-Domain Access was the next topic presented. Quigley had a 
  question about how extended attributes were used in the draft.
  He does not believe that they are sufficient for handling the 
  MAC information.

  Requirements for NFSv4.2 was discussed. It is not an official 
  working group item. There is no commitment from the IESG to 
  recharter the WG to include it.  Lars Eggert is reluctant to allow 
  us to recharter for v4.2 until we have finished off 3530bis.

  Sorin presented on pNFS Access Permissions Check.

  NFSv4 MAC controls was presented. The authors are discussing 
  the different types of MAC methods. 

  There was a talk about sparse files talk. Eisler viewed this 
  as complementary to the deduplication draft.

  Based on the feedback, we appear to be on the right track 
  with FedFS. No AD or IESG issues were raised with the FedFS 
  drafts.

+ No Meeting Next Week

  11/26 is Thanksgiving.

+ Topics for the next meeting (or over email before then):

  - Client Processing of an SRV RR 
  - NFS URL
  - Admin NSDB Trust Anchor Management