[Twg] TWG meeting minutes for 2012-09-06

[John Carrier]

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

We will continue our discussion of the new development RFP at our next meeting:
  Thursday, 9/13/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/20120912/d9062534/attachment.html>
-------------- next part --------------
OpenSFS Technical Working Group
Meeting minutes : 2012-09-06

Concall: start : 9:30a PT 

Next meeting: Thursday, 09/13/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       Intel          adilger at whamcloud.com
   Nic Henke            Xyratex        nic_henke at xyratex.com

Agenda
   Discuss requirements (http://goo.gl/vYmi1) to be covered in an
   OpenSFS RFP.

Notes [from Dave, edited by John]

   During the call, we discussed our prioritized categories and
   attempted  to order the requirements within each category.  We
   discussed the importance of pursuing architectural projects that
   would provide the foundation for  future work.  In the end, we
   reduced the list to the following:  
   
      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

   Overall, the final list is a close blending of the priorities of the
   companies on the board and the community at large.  Regarding the
   projects dropped from consideration:

      - Scalable fault management was on our original list to the board,
         but has been dropped for now as we do not want to duplicate
         on-going R&D efforts. 
      - File creation performance was preferred over single client I/O
         in recognition of Lustre's primary use case, and both were
         deemed more important at the present than directory traversal
         due to recent work in that area. 
      - LNET channel bonding has long been a wishlist item, but we
         believe that it has a dependency on the configuration
         mechanisms, so appears lowest on the list of work items. 
      - Improved LNET robustness remains an important topic, but was
         dropped from this round due to the desire to limit the number
         of items out for RFP and the belief that some of this work
         could be addressed as part of the technical debt of the other
         LNET projects.  

   The ordering of the priorities above should serve as a rough guide as
   to the importance of each project to OpenSFS, but contracts may be
   awarded in a different sequence if doing so would allow OpenSFS to
   achieve a greater impact for the community -- for example if the
   proposals for avoiding RPC timeouts cost the same as doing all of the
   other work, it may make more sense to postpone that work item and
   fund the others.

   We will discuss the form that the RFP will take at our next meeting.
   The current thinking is that we will issue one RFP containing each of
   the above items, but responses will not need to address all areas.
   Each vendor should be able to respond to each area individually, and
   may highlight any benefits derived from combining separate
   requirements under one contract. OpenSFS would expect to evaluate
   each area as a separate item, and may award contracts to separate
   vendors.