[Twg] TWG meeting minutes for 2011-04-28

[John Carrier]

Attached are the meeting minutes from last week's TWG call where we continued the discussion of the release collateral that OpenSFS will require for delivery of features that result from our RFPs.

Please post questions/comments to discuss at lists.opensfs.org<mailto:discuss at lists.opensfs.org>

Next meeting is this Thursday (5/5) @ 9:30a PDT/12:30p EDT, (715) 726-4994, ID/password 72090.


Thanks,

--jc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensfs.org/pipermail/twg_lists.opensfs.org/attachments/20110502/a8ceb969/attachment.html>
-------------- next part --------------
OpenSFS Technical Working Group
Meeting minutes : 04/28/2011

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

Next meeting: Thursday, 5/05/2011 @ 9:30a PDT/12:30p EDT
   Dial-in numbers are 715-726-4994 or 866-304-8294.  
   Meeting ID and password are 72090 (note the new code)

Attending :



   Name              Organization   email
   ----------------- -------------- ----------------------------
   Diego Moreno      Bull           Diego.Moreno-Lazaro at bull.net
   John Carrier      Cray           carrier at cray.com
   Alex Kulyavtsev   FNAL           aik at fnal.gov
   Chris Morrone     LLNL           morrone2 at llnl.gov
   Shay Seager       OpenSFS        shay at opensfs.org
   Dave Dillow       ORNL           dillowda at ornl.gov
   Galen Shipman     ORNL           gshipman at ornl.gov
   Andreas Dilger    Whamcloud      adilger at whamcloud.com
   Eric Barton       Whamcloud      eeb at whamcloud.com
   Nathan Rutman     Xyratex        nathan_rutman at xyratex.com

agenda
   continue discussion of release collateral

discussion

   The current proposal for the release collateral is 
         - high level design (HLD)
         - test plan 
         - test results
         - code inspections for the features (release checklist)
         - standard lustre coding guidelines (coding checklist)


   Check lists :
   
      Last week's meeting ended with descriptions of coding and release
      checklists. Whamcloud has a version of the coding checklist on
      their wiki.  We asked for sources of the release checklist be sent
      to the reflector. Emails to the reflector indicated that CFS
      derived the release checklist from the Software Engineering
      Institute (SEI) at CMU.  As a result, we need to create our own.

      Release checklist items should include well-chosen short-list
      rather than a comprehensive long-list.  Things to consider:
      consistent naming, thread model verification, locking, etc.
      Agreed to take creation of the list to the reflector. 

      AI: chairs to start thread on discuss at lists.opensfs.org
      

   Design docs :

      As part of the release collateral, we need vendors to provide
      design documents for the features they have implemented.  We
      started this discussion by reviewing the docs the Lustre team has
      used in the past:
         ALD = architecture-level design
         HLD = high-level design
         DLD = detail-level design

      The DLD is of more use to the vendor writing the code since it
      includes detailed work flows, procedure skeletons, data
      structures, and anything else needed to guide implementation of
      the code. For the TWG and the rest of the community, the code
      itself will be the documentation for what the design does.  

      We agreed that the TWG needed to see well-written English
      documents describing the ideas behind the design, similar to the
      HLDs that the Lustre team had generated before.  This high-level
      design document will describe the ideas behind the design and
      provide background to anyone reading the code.  It should include
      a description of the implementation (but no procedure or structure
      definitions) and diagrams needed to clarify the design. Vendors
      will be expected to update the document after the implementation
      is complete as part of the release collateral.
      
      The HLD represents considerable work.  Vendors need to engage the
      community with the architectural overview of the design to ensure
      that they have addressed the requirements and provided the
      necessary scope.   This solution architecture is recorded in the
      ALD.

      We agreed that statements of work (SOWs) for feature development
      resulting from the OpenSFS RFPs will require two reviews prior to
      feature implementation.  The first will review the proposed
      architecture and its scope (ALD) and the second will review the
      high-level design (HLD).  The documents will be posted to the
      OpenSFS website and the TWG will hold concalls for each review. We
      will investigate whether we can record the meetings for those
      unable to attend the concalls. 

      Summary: 

         * The TWG will require an ALD and HLD for OpenSFS SOWs
            - The ALD provides a review of the requirements and an
               outline and scope of the architecture before proceeding
               to the HLD.
            - The HLD provides a description of the architecture and an
               overview of the implementation.
            - The vendor will review both documents during a TWG
               concall with the Lustre community.

         * The HLD will be required as release collateral 
            - We expect anyone contributing new features to the
               Lustre canonical tree to provide this document before
               a code review.

      We also discussed the need for more than one deliverable during
      the implementation phase.  The OpenSFS RFPs provide this structure
      and we should expect the SOW to make those deliverables explicit.
      

   Test Plan 
      

      We then spent time discussing the test plan.  We recognized that
      not all features, because of their scope, can be tested with
      well-defined unit-tests.  We need to allow for these features to
      be tested with system tests.   The TWG should review the test plan
      as part of the SOW for OpenSFS RFPs.

      The test plan should be an english description of the tests of new
      functionality that verifies the new code does not negatively
      affect existing functionality.  The plan needs to include a
      minumum scale required to test the feature.  Reviewers may also
      require a minumum scale for the tests before allowing the review
      to complete.

      AI: Whamcloud agreed to provide text describing the test plan

   
   Inspectors

      It was suggested on the reflector that we pre-register inspectors.
      Gerrit, which Whamcloud is using, allows anyone to sign up as an
      inspector.  While we want to encourage broad review, OpenSFS
      needs inspection by at least one recognized expert.
      
      We agreed to send out a call to the community for people who feel
      knowledgable enough to review code.  Inspectors must also
      indicate the subsystems they feel competent to review.

      AI: chairs to send out inspector request

adjourned 10:35