<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head><body>
<p>DefCore,</p>
<p><br /></p>
<p>We're back in the flow AND items are moving into Gerrit for reviews. </p>
<p><br /></p>
<p>PLEASE TAKE TIME TO REVIEW THE PATCHES.</p>
<p><br /></p>
<p># Meeting Summary<br />* Reviewed Board activity including 2015.03 docs in review > https://review.openstack.org/#/c/162655/<br />* Discussed using tests that were not tempest<br />* Agreed tp setup 2015.next (target 2015.04) for review > https://review.openstack.org/#/c/164398/ <br />* Reviewed progress on process by Rob & Egle [draft in notes]<br /></p>
<p><br /></p>
<p>Full Link: <a href="https://etherpad.openstack.org/p/DefCoreScale.7">https://etherpad.openstack.org/p/DefCoreScale.7</a></p>
<p><br /></p>
<p>Here are the complete notes:</p>
<p><br /></p>
<p># DefCore Scale.72015, March 13 @ 9am PT<br />Previous: <a href="https://etherpad.openstack.org/p/DefCoreScale.6">https://etherpad.openstack.org/p/DefCoreScale.6</a>Following: <a href="https://etherpad.openstack.org/p/DefCoreScale.8">https://etherpad.openstack.org/p/DefCoreScale.8</a><br /># Summary* Reviewed Board activity including 2015.03 docs in review > <a href="https://review.openstack.org/#/c/162655/">https://review.openstack.org/#/c/162655/</a>* Discussed using tests that were not tempest* Agreed tp setup 2015.next (target 2015.04) for review > <a href="https://review.openstack.org/#/c/164398/">https://review.openstack.org/#/c/164398/</a>* Reviewed progress on process by Rob & Egle [draft in notes]<br /># Agenda</p>
<ul>
<li>Review Board Action</li>
</ul>
<ul>
<li>Capabilities Updates</li>
</ul>
<ul>
<li>Create Drafts for 2015.Next guideline from 2015.03</li>
</ul>
<ul>
<li>Tests beyond Tempest</li>
</ul>
<ul>
<li>Review Process Materials</li>
</ul>
<p><br /><br />Roll Call:</p>
<ul>
<li>Mark Voelker (VMware)</li>
</ul>
<ul>
<li>Vince Brunssen (IBM)</li>
</ul>
<ul>
<li>Rob Hirschfeld (co-chair)</li>
</ul>
<ul>
<li>John Dickinson</li>
</ul>
<ul>
<li>Chris Lee (DreamHost)</li>
</ul>
<ul>
<li>Carol Barrett (Intel)</li>
</ul>
<ul>
<li>Catherine Diep (IBM)</li>
</ul>
<ul>
<li>Chris Hoge (OpenStack Foundation)</li>
</ul>
<p><br /># Spec<br /><a href="https://review.openstack.org/#/c/162655/2">https://review.openstack.org/#/c/162655/2</a><br />VOTE: Current specs format for .NEXT spec: +1+1+1+1+1+1<br /># Using Non Tempest Tests for DefCore<br />DefCore was not limited to Tempest on purpose.Technical Community is moving tests into projects<br />How can we include other tests?</p>
<ul>
<li>Yes – that was part of the design</li>
</ul>
<ul>
<li><br /></li>
</ul>
<p>What if tests are not working?</p>
<ul>
<li>Capabilities are a good way to handle that</li>
</ul>
<ul>
<li>Flagged Tests may be able to address in short term</li>
</ul>
<p><br /># Working on Process Text (RST)<br />Process Definition--------------------------------------<br />The DefCore Guideline process has two primary phases: Draft and Review. During the Draft phase (A), the DefCore Committee is working with community leaders to update and score the components of the guideline. During the Review phase (B), general community and vendors have an opportunity to provide input and check the guidelines (C) against actual implementations. Review phase ends with Board approval of the draft guideline (D).<br />This section provides specific rules and structure for each phase.<br />Guidelines Draft Phase (A) ^^^^^^^^^^^^^^^^^^^^^^^^^^<br />Starting: S-3<br />A1. New Guidelines Start From Previous<br /> 1. Receive DefCore Dedicated Section Guidelines #. New Guidelines start from the previous Board approved document.<br />2. Community Groups Tests into Capabilities<br /> 1. DefCore Committee coordinates community activities with the TC and PTLs to revise the capabilities based on current technical needs and functionality. <br /> 1. Groupings may change between iterations<br /> #. Acceptable Tests<br /> 1. Tests must have unique identifiers to be considered that are durable between releases #. Tests must be under OpenStack governance<br />3. PTLs Recommend Changes to Designated Sections<br />4. DefCore Committee identifies required capabilities<br /> 1. DefCore uses Board approved DefCore scoring criteria to evaluate capabilities.<br /> #. DefCore needs Board approval to change scoring criteria. #. Scoring criteria factor or weights cannot change after Draft is published.<br /> #. DefCore identifies cut-off score for determining that a capability is required. #. Capabilities will not be removed without being deprecated in the previous Guideline. #. Capabilities will not be added without being advisory in the previous Guideline.<br />5. Foundation recommends OpenStack Components and OpenStack Platform Scope<br /> #. Foundation recommends capabilities to include in each OpenStack Component #. Foundation recommends which Components are required for the OpenStack Platform<br />6. DefCore Committee creates recommendation for Draft.<br /> #. DefCore Committee coordinates activities to create draft. #. DefCore Committee may choose to ignore recommendations with documented justification.<br /><br />Guidelines Review Phase (B)^^^^^^^^^^^^^^^^^^^^^^^^^^^<br />Starting: Summit<br />B1. All Reference Artifacts are reviewed via Gerrit<br /> #. Draft Guideline #. Designated sections #. Test-Capability groupings #. Flagged Test List #. Capability Scoring criteria and weights #. Not in Gerrit: Working materials (spreadsheets, etc)<br />B2. Presentation of Draft Guidelines<br /> #. DefCore will present the Draft Guidelines to the Board for Review #. DefCore will distribute Draft Guidelines to the community #. Foundation provides Draft to vendors for review<br />B3. Changes to Guideline made by Gerrit Review Process<br /> #. Community discussion including vendors must go through Gerrit #. All changes to draft must go through Gerrit process<br />CONCERN: Issues raised late in process should not be allowed to stall process<br /><br />Community Review & Vendor Self-Test (C)^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^Starting: S and continues past S+3<br />C1. Vendor Self-Tests<br />C2. Vendor submits results to Foundation<br /><br />C3. Vendor Grievance Process<br />C4. Results of Vendor Self-Tests will be open<br /><br />C5. API Usage Data Collection<br /><br />Guideline Approval (D)^^^^^^^^^^^^^^^^^^^^^^<br />Starting: S+3<br />D1. Board will review and approve DefCore Guideline draft<br /> 1. Guidelines are set at the Platform, Component and Capability level only #. Text guideline document is authorative over the JSON representation #. DefCore will provide JSON representation for automated scoring<br />D2. DefCore Committee has authority on test categorization<br /> 1. Can add flagged tests before and after Guideline approval #. Cannot change Test to Capability mappings after approval #. Maintains the test to capability mappings in the JSON representation<br />D3. Designated sections only enforced for projects with required capabilities.<br /></p>
<ul>
<li>1. Designated sections may be defined for any project</li>
</ul>
</body></html>