<!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>All, </p>
<p><br /></p>
<p>We had a good 2015 kickoff meeting today. Next meeting 2/4 @ 9am PT.</p>
<p><br /></p>
<p>## Summary:</p>
<p>Basic kick-off meeting to launch Capabilities & Process sub committees. <br /></p>
<ul>
<li>Due to amount of work, expect bi-weekly (or more frequent) meetings. <br /></li>
<li>Chris Hoge will be coordinating the coordinating the capabilities meetings<br /></li>
<li>Rob Hirschfeld will be coordinating the process meetings<br /></li>
<li>Calendar of deliverables is very aggressive!<br /></li>
<li>We need to have a new board co-chair for the committee.<br /></li>
</ul>
<p>Here are the foll minutes: <a href="https://etherpad.openstack.org/p/DefCoreScale.2">https://etherpad.openstack.org/p/DefCoreScale.2</a></p>
<p><br /></p>
<p>DefCore Scale.2<br />Kick-off Meeting for 2015 to set the agenda for this cycle. ## Agenda: We have two major threads to complete before the Vancouver summit:</p>
<ul>
<li>Refstack status</li>
</ul>
<ul>
<li>Review December Approvals</li>
</ul>
<ul>
<li>Co-chair replacement</li>
</ul>
<ul>
<li>TC Cross Membership – Monty & Russel</li>
</ul>
<ul>
<li>Meeting Cadence</li>
</ul>
<ul>
<li>Capabilities scoring for Board approval.</li>
</ul>
<ul>
<li>Define the detaile DefCore process for Board and TC approval</li>
</ul>
<p>## Minutes:Roll Call:</p>
<ul>
<li>Rob Hirschfeld</li>
</ul>
<ul>
<li>Vince Brunssen</li>
</ul>
<ul>
<li>Mark T. Voelker</li>
</ul>
<ul>
<li>Chris Hoge</li>
</ul>
<ul>
<li>Carol Barrett</li>
</ul>
<ul>
<li>Will Auld</li>
</ul>
<ul>
<li>Rocky Grober</li>
</ul>
<ul>
<li>Russell Bryant</li>
</ul>
<p><br />## Refstack/Testing<br />Background: Refstack is intended to collect vendor data from multiple clouds for comparision. It is not required for DefCore but helpful.Status:</p>
<ul>
<li>Client in pretty good shape</li>
</ul>
<ul>
<li>Documentation, feedback, documentation.</li>
</ul>
<ul>
<li>I (Chris Hoge) am here to help! Ask lots of questions and give me a hard time when things go wrong.</li>
</ul>
<ul>
<li>Would like to run only defined capability tests (~160 for core capabilities) rather than 1000+ API tests</li>
</ul>
<ul>
<li>Modest amount of development effort</li>
</ul>
<ul>
<li>Tempest UUID is imperative to go forward so we can start patching Tempest tests that have bugs not caught by Devstack.</li>
</ul>
<ul>
<li><a href="https://review.openstack.org/#/c/144329/2/specs/meta-data-and-uuid-for-tests.rst,cm">https://review.openstack.org/#/c/144329/2/specs/meta-data-and-uuid-for-tests.rst,cm</a></li>
</ul>
<ul>
<li>Gathering beta testers final weeks of January for beginning testing in Febrary</li>
</ul>
<ul>
<li>List to reach out to:</li>
</ul>
<ul>
<li>Private/Distro</li>
</ul>
<ul>
<li>Metacloud/Cisco</li>
</ul>
<ul>
<li>SuSE</li>
</ul>
<ul>
<li>Mirantis</li>
</ul>
<ul>
<li>IBM</li>
</ul>
<ul>
<li>VMWare</li>
</ul>
<ul>
<li>Public</li>
</ul>
<ul>
<li>HP</li>
</ul>
<ul>
<li>Rackspace</li>
</ul>
<ul>
<li>Bluebox</li>
</ul>
<ul>
<li>Dreamhost</li>
</ul>
<ul>
<li>Goal is to have meaningful vendor participation for Vancouver, with scoring in Marketplace.</li>
</ul>
<ul>
<li>Refstack server not to be used as is, but remains in consideration</li>
</ul>
<ul>
<li>Requirements of security (identity, auth, schema validation, rate limiting)</li>
</ul>
<ul>
<li>Demonstrated history of maintenance and project leadership</li>
</ul>
<ul>
<li>Foundation staff liked score card, may use skinned/modified version for Marketplace</li>
</ul>
<p><br />## Approved items from December 2014<br /><strong>1) Role for Foundation on DefCore</strong><br />I felt that it was important to have an official role for the Foundation so that meetings and announcements could make official progress even without having one of the Chairs involved. There is substantial work to be done and we cannot be limited by the schedule of the chairs. After discussing several options including leaving it <em>ad hoc</em>, everyone on the call agreed that having an official Secretary would address all concerns. There's an expectation, not a requirement, that the Secretary is also on the Foundation staff.<br />Since this is internal to the committee, we can act on it immediately. If you have concerns, please raise this here! If not, please +1.+1<br />> APPROVED: Appoint Foundation staffer, Chris Hoge, to be DefCore Secretary for the Scale cycle.<br /><strong>2) Burn Down Calendar for Icehouse & Juno</strong><br />Companies will want to prepare to make statements in Early April so that Board needs to approve capabilities in early April! That means we need to target March 3rd to have Juno capabilities in community review! Ideally, we can mainly focus on deltas from Havana and this work can go quickly.<br />We considered that it likely practical to review Icehouse and Juno in parallel since they are additive.<br />> APPROVED: Form subcommittee to start capabilities review process. Coordinated by DefCore Secretary.<br /></p>
<ul>
<li>January</li>
</ul>
<ul>
<li>Refstack-client mods to run only defcore capabilities test</li>
</ul>
<ul>
<li>Process documentation.</li>
</ul>
<ul>
<li>Beta tester recruitement.</li>
</ul>
<ul>
<li><em>February</em></li>
</ul>
<ul>
<li>Evaluating tests, writing new tests</li>
</ul>
<ul>
<li>Remove admin requirements?</li>
</ul>
<ul>
<li>UUID Implementation</li>
</ul>
<ul>
<li>Clean up environment after running tests</li>
</ul>
<ul>
<li>Private beta testing concurrent</li>
</ul>
<ul>
<li><em>March</em></li>
</ul>
<ul>
<li>Partner Testing</li>
</ul>
<ul>
<li><em>April</em></li>
</ul>
<ul>
<li>Partner Testing, Markteplace buildout.</li>
</ul>
<p><br /><strong>3) Decoupling Refstack</strong><br />DefCore is about defining the tests, not scoring them. We have clear needs for a project like Refstack to help score vendors and collect usage data, it's not a blocker for our process. We want to support Refstack; however, we also need to keep DefCore timelines. For that reason, it's important to acknowledge that DefCore, as approved by the Board, is not dependent on Refstack milestones.<br />> APPROVED: For Scale cycle, vendors can SELF-CERTIFY that they meet the DefCore criteria without any additional validation. Ideally, we'd have Refstack to allow them to prove compliance; however, we cannot commit to that right now. Basically, we are agreeing to take vendors at their word at this point.<br />## Co-chairs<br />We are looking for a co-chair – must be a board member. Please contact Rob Hirschfeld with interest.<br />## TC Cross Membership<br />Monty & Russel chosen by the TC because they are cross membership w/ Board. Thierry is their backup.<br />Focus on process side.<br />## Meeting Cadence<br />Q: Can we have an 8am PT start for meetings to be more EU friendly? +1-1+1Weekday preferences: no TUESDAY! (MWF), No FRIDAY Poll: Please +/- 1 : 8;00am+1+1+1-1 8:30am +1+1+1+1+1WINNER > 9:00am+1 +1+1+1+1+1 10:00am +1+1+1<br />Need to have at bi-weekly DefCore meeting (subcomittees will be active too) to ensure status & schedule updates.</p>
<ul>
<li>> at least having bi-weekly status reports to list.</li>
</ul>
<p><br />Open Doors for the Secretary & Chairs – communicate issues quickly<br />## Capabilities Sub Commitee<br />> Chris Hoge & Van L leading.<br />Need to engage technical review / PTLs<br />Goals this subcommittee: 1) draft the capabilities documents 2) identify the capabilities (changes from Havana)</p>
<ul>
<li>2.a) Sample of results of defcore capabilities meeting with Keystone PTL <a href="https://etherpad.openstack.org/p/keystone-defcore">https://etherpad.openstack.org/p/keystone-defcore</a></li>
</ul>
<p>3) add new tests into capability and add capabilities 4) score the capabilities 5) designated sections also need to be reviewed 6) identify flagged testsWe _hope_ that I & J in parallel. Icehouse is primary target.<br />Expected trend is weekly cadence but not all people have to attend all meetings. Chris is the common thread.<br />DECISION: Chris has authority to work 1x1 or in groups to collect and review this data. Please advise via the DefCore list if there is a planned meeting so that we have visiblity and option to join.<br />## DefCore Process<br />> Rob & Russell coordinating<br />Bylaws changes require having a documented process. Process needs to be approved by the TC & Board.<br />Goals: 1) draft a process (as patch) for TC & Board approval 2) vet process in community 3) find new home for .json files (if needed) 4) timeline – should be presented to Board for March f2f meeting 5) post Board & TC review, needs to be go legal review (mid-March target)Expected trend is weekly cadence. There should not be out-of-band meetings.<br /># SAMPLE:<br /><span style="text-decoration: underline;">Drawing: </span><a href="https://wiki.openstack.org/wiki/File:DefCoreProcessFlow.pdf"><span style="text-decoration: underline;">https://wiki.openstack.org/wiki/File:DefCoreProcessFlow.pdf</span></a><br />The following items are key points:</p>
<ol>
<li>We are using the documents in the <strong>Gerrit review process</strong> to ensure that we work within the community processes.</li>
</ol>
<ol>
<li>Going forward, we want to <strong>rely on the technical leadership</strong> to create, cluster and describe capabilities. DefCore bootstrapped this process for Havana. Further, Capabilities are defined by tests in Tempest so test coverage gaps (like Keystone v2) translate into Core gaps.</li>
</ol>
<ol>
<li>We are investing in data driven and <strong>community involved feedback</strong> (via Refstack) to engage the largest possible base for core decisions.</li>
</ol>
<ol>
<li>There is a <strong>“safety valve” for vendors</strong> to deal with test scenarios that are difficult to recreate in the field.</li>
</ol>
<ol>
<li>The <strong>Board is responsible</strong> for approving the final artifacts based on the recommendations. By having a transparent process, community input is expected in advance of that approval.</li>
</ol>
<ol>
<li>The <strong>process is time sensitive</strong>. There’s a need for the Board to produce Core definition in a timely way after each release and then feed that into the next one. Ideally, the definitions will be approved at the Board meeting immediately following the release.</li>
</ol>
<p><br /><br /><br /><br /></p>
</body></html>