[Twg] TWG meeting minuts for 2012-09-13

[John Carrier]

The minutes from our OpenSFS TWG meeting last week are attached.  Please send comments and/or corrections to the reflectors.

We plan to continue discussion of the RFP at our next call
  Thursday, 9/20/2012  @ 9:30a PDT/12:30p EDT
   Dial-in numbers are 1-715-726-4994 or 1-866-304-8294
   Meeting ID and password are 72090
--jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensfs.org/pipermail/twg_lists.opensfs.org/attachments/20120920/89d2734b/attachment.html>
-------------- next part --------------
OpenSFS Technical Working Group
Meeting minutes : 2012-09-13

Concall: start : 9:30a PT, adjourn : 10:32 PT

Next meeting: Thursday, 09/20/2012 @ 9:30a PDT/12:30p EDT
   Dial-in numbers are 1-715-726-4994 or 1-866-304-8294
   Meeting ID and password are 72090

Attending

   Name                 Organization   email
   -----------------    -------------- ----------------------------
   Cory Spitz           Cray           spitzcor at cray.com
   John Carrier         Cray           carrier at cray.com
   Alex Kulyavtsev      FNAL           aik at fnal.gov
   Steve Simms          IU             ssimms at indiana.edu                            
   Joshua Walgenbach    IU             jjw at indiana.edu
   Dave Dillow          ORNL           dillowda at ornl.gov
   Andreas Dilger       Whamcloud      adilger at whamcloud.com
   Nathan Rutman        Xyratex        nathan_rutman at xyratex.com

Notes
   John sent the RFP from last year to the TWG reflector (and knows that
   he needs to put it on the twg wiki along with other docs that appear
   to have been lost from the opensfs website).

   DaveD reviewed the notes from last week and the proposed priority
   order of the requirements: 

         FS Availability
            1. Avoid RPC Timeouts
         Storage Management
            2. HSM and storage management infrastructure
            3. OST migration and rebalancing
         Performance
            4. File creation performance
            5. Single client I/O performance
         Lustre Networking
            6. Dynamic LNET configuration
            7. LNET channel bonding

      There were no objections to this plan.

   - acceptance criteria
      We discussed the need for including acceptance criteria in the
      statement of work resulting from this RFP.  If there is no
      performance improvement, vendors must, at a minimum, show no
      regression in performance or functionality.  These criteria will
      be negotiated during the SOW.

   - requirements
      The RFP needs to be requirements based.  The TWG learned the last
      time that the Board will not accept feature descriptions in the
      RFP.  Instead we must craft the RFP in terms of requirements.  The
      proposals will have to describe how they meet the requirements and
      what expected gains their solutions will offer.
      
   - separating design and implementation 
      Unlike our previous RFP, the requirements cover a broad area and
      it is not necessarily clear what the correct implementation should
      be to meet these requirements.  We discussed the need to split
      each RFP into separte investigation and implementation phases.  

      Our current development contracts use the following stages:
            Scope Statement 
            Solution Architecture 
            High-Level Design
            Implementation
            Demonstration
            Delivery

      The proposal being discussed would split these into two groups:

         Investigation  Phase          Implementation Phase
            Scope Statement               Implementation
            Solution Architecture         Demonstration
            High-Level Design             Delivery
        
      Seperating design from implementation will make it easier for
      vendors to estimate the costs.  Estimating the implementation
      before the design is complete is tricky and prone to errors. 
      
      For example, Cray structured its HPCS SOW with Sun along these
      lines (which lead to initial designs for CMD, channel bonding,
      LFSCK, end-to-end data integrity, etc.  follow the link for more
      info: http://wiki.lustre.org/index.php/Lustre_HPCS_Activities).  

      The last item of Cray's design SOW with Sun was a proposal for the
      implementation.  We could do the same here, or we could issue a
      separate RFP for the implementation to engage more developers in
      the program.
      
   - proof of concept
      We discussed the need for considering proof of concept (POC) as a
      separate stage for new feature development.  This should be part
      of the implementation, but would be used to demonstrate the
      viability of the proposed design.  Successful demonstration of the
      POC would provide a decision point for continuing development and
      productiztion of the feature.

   - number of RFPs
      We may end up issuing multiple RFPs, but for now, we will create
      the RFP as a single document with several sub-categories. This
      will help minimize the admin overhead.  In either case, vendors
      can respond to subsections, not the complete RFP. 
      
end 10:32PTq