[nfsv4] [FedFS] Meeting Minutes, 9/30/2010
James Lentini <jlentini@netapp.com> Thu, 30 September 2010 19:50 UTC
Return-Path: <jlentini@netapp.com>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D13F3A6E71 for <nfsv4@core3.amsl.com>; Thu, 30 Sep 2010 12:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=-3.418, BAYES_00=-2.599, FB_REPLIC_CAP=6.557, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdwSVyaubKXe for <nfsv4@core3.amsl.com>; Thu, 30 Sep 2010 12:50:44 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 1B22B3A6E67 for <nfsv4@ietf.org>; Thu, 30 Sep 2010 12:50:44 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.57,261,1283756400"; d="scan'208";a="460941361"
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 30 Sep 2010 12:51:30 -0700
Received: from jlentini-linux.hq.netapp.com (jlentini-linux.hq.netapp.com [10.97.16.21]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o8UJpULg014468 for <nfsv4@ietf.org>; Thu, 30 Sep 2010 12:51:30 -0700 (PDT)
Date: Thu, 30 Sep 2010 15:51:29 -0400
From: James Lentini <jlentini@netapp.com>
X-X-Sender: jlentini@jlentini-linux.nane.netapp.com
To: nfsv4@ietf.org
Message-ID: <alpine.LFD.2.00.1009301550320.21841@jlentini-linux.nane.netapp.com>
User-Agent: Alpine 2.00 (LFD 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: [nfsv4] [FedFS] Meeting Minutes, 9/30/2010
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Sep 2010 19:50:45 -0000
FedFS Meeting Minutes, 9/30/2010 -------------------------------- Attendees --------- Andy Adamson (NetApp) Craig Everhart (NetApp) Sorin Faibish (EMC) James Lentini (NetApp) Chuck Lever (Oracle) Paul LeMahieu (EMC) Peter Staubach (EMC) Robert Thurlow (Oracle) Mark Uddin (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. + October Bake-a-thon Planning Mark Uddin has been configuring equipment for the Bake-a-thon. He has installed and configured a DNS server on a Windows 2008 Server for use testing the NFS DNS SRV record. This machine will also be used for other purposes: VMware vCenter, pNFS testing. Mark asked if this DNS server will be useful for the NFS DNS SRV testing. Rob expected that it would be fine if it could return a standard DNS SRV record. Mark reported that the NFS DNS SRV record is not setup yet on the server. This DNS server will also be the DHCP server for the event. We haven't tested this configuration yet, but we would expect it to work Chuck asked if want to do IPv6 testing and if so does this DNS server support IPv6? Mark was unsure of the IPv6 support. We will check on this. Chuck requested that we have a procedure for installing an SRV record on this system. Mark asked for a pointer to the NFS DNS SRV specification. [Editor's Note: the draft is here: http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-dns-srv-namespace-05] Craig Everhart will send Sorin an email with the important points of the NFS DNS SRV record. Sorin reported that the Bake-a-thon talk agenda is available on the website: http://www.citi.umich.edu/projects/nfsv4/citi_bakeathon/15th_nfsv4_bakeathon.html There will be conference rooms for break-out meeting with polycom phones if someone needs to use them. The wireless network will allow for outbound VPN traffic. The wired network configuration has already been defined. Sorin will send specifics on the IP addresses. There is time on Friday to discuss ad hoc issues and summarize. Sorin will send his cell phone in case any issues arise during the weekend. + FEDFS_*_REPLICATION Craig noticed two items on a second reading of the draft. First, the description of the FEDFS_*_REPLICATION procedures is relatively clear that they set the FSN for a present fileset, but don't manage a replication relationship between fileservers. However, he could imagine some confusion in this area and may propose additional text to make this point more obvious. Secondly, Craig pointed out that the FEDFS_CREATE_REPLICATION procedure's behavior when an "replication" FSN is already set on a fileset is undefined. The FEDFS_CREATE_JUNCTION procedure will fail with FEDFS_ERR_EXIST. We agreed that the behavior of FEDFS_CREATE_JUNCTION and FEDFS_CREATE_REPLICATION do not need to be the same. For FEDFS_CREATE_REPLICATION, Craig proposed that this procedure act a if it were setting an attribute and so it should succeed if called on a fileset with an existing "replication" FSN. Rob agreed with Craig's proposed behavior. We discussed if implementing the FEDFS_*_REPLICATION procedures are required (MUSTs) or optional (SHOULDs) for internal nodes in the namespace. Rob observed that if NFS4ERR_MOVED is not returned for an object, the NFS server is not required to support fs_locations. Therefore, the FEDFS_*_REPLICATION procedures should be optional (SHOULDs or even MAYs). We agreed to list these as SHOULDs in the next revision. Chuck asked if this attribute follows a copy of a filset? Chuck observed that one way to implement this in Linux is to use a filesystem's UUID to location its "replication" FSN value. With that implementation, it would be somewhat cumbersome for a copy of the filesystem (with different UUID) to locate its "replication" FSN value and return the same fs_locations value. Rob noted that NFSv4's replication support is designed to work across heterogeneous servers. In many instances, a "cp -r" command will be sufficient to create a replica. For that reasons, it seemed prudent to pursue Linux designs other than the one described above. Chuck asked if there recommendations on how to generate a UUID. James suggested that folks review recommendations in Section 4.2.1.1 of draft-ietf-nfsv4-federated-fs-protocol-09 and reply with feedback. We noted that the FEDFS_*_REPLICATION procedures have not be implemented in either Linux or Solaris yet. + Admin Draft Update Draft -06 was posted on 9/29 with the following changes: - Each procedure now lists the errors it is allowed to return - In 5.2.1, the description of FEDFS_DELETE_JUNCTION indicated that if the targeted object was not a junction, the error would be FEDFS_ERR_INVAL. In similar situations in other parts of the specification, the error is FEDFS_ERR_NOTJUNCT. The FEDFS_DELETE_JUNCTION description was corrected to use the FEDFS_ERR_NOTJUNCT error. - The NOTEMPTY and NOTDIR error codes were removed since they were no longer in use (text that referred to them was removed from FEDFS_CREATE_JUNCTION in the previous revision). - Error codes (FEDFS_ERR_NSDB_REFERRAL, ...) and text (5.3.2) was added for LDAP referrals. - Type names used by both the JUNCTION and REPLICATION functions were renamed for consistency (see CreateJunctionArgs, FedFsLookupArgs, and FedFsLookupRes). - Added a FEDFS_ERR_DELAY and FEDFS_ERR_NOTSUPP error values - Added cache lookup error codes (FEDFS_ERR_NO_CACHE, FEDFS_ERR_UNKOWN_CACHE, and FEDFS_ERR_NO_CACHE_UPDATE) - Added a synopsis for each procedure - Added a description of the FEDFS_NULL procedure (5.1) Chuck had a list of questions for the group. - Should there be an error code for when an NSDB is missing an NCE? This seemed like a reasonable addition. We'll add an FEDFS_ERR_NONCE error to every procedure where NOFSN or NOFSL are allowed. - What should be the error code if the NSDB returns a permission error? We agreed that FEDFS_ERR_NSDB_LDAP_VAL can be used for this case. - What should be the error if an FSL object is missing information? There is an existing error code, FEDFS_ERR_NSDB_RESPONSE, for malformed responses. We'll expand on the description of this error to note some of situations (like this one) in which it should be used. + Multi-domain Access Draft update Andy has updated the multi-domain access draft. He has sent an email to the WG reflector summarizing the changes and asking for feedback on certain points. We will schedule time to discuss this at a future meeting. + Meeting Schedule Our next meeting will be on October 14.
- [nfsv4] [FedFS] Meeting Minutes, 9/30/2010 James Lentini
- Re: [nfsv4] [FedFS] Meeting Minutes, 9/30/2010 Chuck Lever
- Re: [nfsv4] [FedFS] Meeting Minutes, 9/30/2010 James Lentini
- Re: [nfsv4] [FedFS] Meeting Minutes, 9/30/2010 Trond Myklebust
- Re: [nfsv4] [FedFS] Meeting Minutes, 9/30/2010 James Lentini
- Re: [nfsv4] [FedFS] Meeting Minutes, 9/30/2010 Trond Myklebust
- Re: [nfsv4] [FedFS] Meeting Minutes, 9/30/2010 James Lentini
- Re: [nfsv4] [FedFS] Meeting Minutes, 9/30/2010 Everhart, Craig
- Re: [nfsv4] [FedFS] Meeting Minutes, 9/30/2010 Robert Thurlow
- Re: [nfsv4] [FedFS] Meeting Minutes, 9/30/2010 Thomas Haynes
- Re: [nfsv4] [FedFS] Meeting Minutes, 9/30/2010 Robert Thurlow