Open Stack

All,

I've very excited about the progress DefCore made last week.  Here are our notes.

Rob

## Summary (compiled by Rob Hirschfeld)


  *   completed detailed timeline for cycle including communications and review deadlines

  *   finished scoring the capabilities matrix

  *   reviewed Refstack mockups and API specification standards

  *   took a position on Swift (some swift APIs should be core but cannot if there's designated code)

  *   decided to move tests into capabilities for scoring.  PTLs choose which tests but DefCore can exclude/flag tests

  *   made great progress on bylaws change "in plain english" (IPE) for review in next meeting

Full Text: Below and https://etherpad.openstack.org/p/DefCoreLighthouse.F2F


DEFCORE MEETING 6/12 AGENDA (Lighthouse.F2F)
#######################################################


## Attendeees list

  *   Rob Hirschfeld (present)

  *   Todd Moore (present)

  *   Mark Atwood (present)

  *   Joshua McKenty (present)

  *   David Lenwell (semi-present)

  *   Eileen Evans (present, late)

  *   Nissa M. Strottman (present)

  *   Phil Estes (remote)

  *   Sean Roberts (omni-present)

  *   Rocky Grober (semi-present)

  *   Swapnil Kulkarni (Following etherpad & #refstack)

## Agenda (10:00)


  *   (done) Refstack Updates

  *   (done) Swift

  *   Havana Matrix Completed

  *   Swift in Core

  *   (done) Discuss Capability Score Process (by test or capability, how track changes to score, how to include new tests)

  *   Swagger / RAML

  *   Review Mock Ups of Reports in refstack specs??

  *   (done) Comms / OpenStack Blog Post

  *   Interop objectives and progress

  *   API review (Kin Lane)

  *   (done) Timing for Cycle

  *   Schedule Community Meeting (2) to review matrix [blocked until matrix is done]

  *   (done) Discuss Bylaws change proposal, plan for community review, process document (done)

  *   https://etherpad.openstack.org/p/DefCoreLighthouse.Bylaws1


## REFSTACK UPDATES (10:14):

http://etherpad.openstack.org/p/refstack.2014-06-11
https://storyboard.openstack.org/#!/project/700
https://github.com/stackforge/refstack/tree/master/specs

We are going to rely on community test runs for now instad of automation test runs.
  * solves issues of refstack having to protect/track credentials
  * takes burden off of infra team to run/troubleshoot workers
  * will ultimately be something we do starting from the "private refstacks"

Refstack will be more about data collection and reporting (hosted by infra team)

  *   * will be API end-point

  *   * made progress yesterday on API spec yesterday

  *
Cloud identity is an important thing to manage - multiple tests from same cloud need to be grouped
  * allows multiple people to run tests independently and then aggregate the results
  * potential issue could be that QA runs will inflate the results
  * identifier will not be hash of API endpoint url, but will instead be keystone identity uuid

Process discussion
  * Refstack is using latest approaches OpenStack process structure
  * Likely moving to the infra tree in th next few weeks
  * slides on refstack workflow: https://docs.google.com/presentation/d/1SGQCEFyU7B0Ty6rq90arB3MjwPhMqViZTXi1Ggn2xFs/edit?usp=sharing
  * we will run our own Storyboard instance on a free Dreamcompute

Branchless Tempest Decision / Pass Only Tests
  * we are following QA teams advise on which branch of Tempest
  * pass only helps product data & vendor

Rob about pace and progress
  * we are working to bring the community along on this not work around it
  * this is a core value to bringing us along

ACTION > Refstack to focus on Icehouse collection.  No extra work for Havana

## Swift

We completed scoring Object store.  All the remaining items were "on the bubble" on the OUT side

https://docs.google.com/spreadsheet/ccc?key=0Av62KoL8f9kAdFo4V1ZLUFM0OHlrRnFpQUkxSHJ5QWc&usp=drive_web#gid=6
https://docs.google.com/a/pistoncloud.com/spreadsheet/ccc?key=0Av62KoL8f9kAdEJTWnFWejJySnFXZmxWdnowTDhUSVE&usp=drive_web#gid=0

Picking designated sections for Swift > we are in a position to choose 0 or 100 without any intermdiate.

DefCore agrees that the TC is the deciding body for designated sections.

Official position, DefCore asks TC to resolve Swift D.S. question.

ACTION > Rob to take to TC that if Swift has any designated sections then the DefCore committee will likely recommending omitting the "object-*" capabilities from core.
ACTION > DefCore request to reconsider the default designated section position may not be as Apache 2 friendly
ACTION > Add "flagged" to the lexicon page - https://wiki.openstack.org/wiki/Governance/DefCoreLexicon


  *   Designated Sections > https://review.openstack.org/#/c/84712/

  *
## Score Capabilities

Tests in core capabilities are "required" in all cases EXCEPT where we have concerns about the tests.  We consider those to be "FLAGGED"

Vendors do not have to pass "flagged" tests

PTL will own tests in capabilities
DefCore will own which tests are flagged

ACTION > Write up on Process including a JSON diff between Havana & Icehouse
ACTION > Update the JSON for Refstack (Rob)

## API Specs (Swagger)

Ultimately, we'd like to have the projects manage their own tests > capabilities mapping
Would be very helpful to have a consistent way to document the APIs __AND__ have the documentation indicidate which APIs are CORE.
  * REPEATING > we would like the APIs tested by Core capabilities to be metadata-labelled as "core APIs"

Refstack is using Swagger as an example to help explain the value prop

ACTION > Get the Foundation Staff to add the indexing plugin to etherpad.

## Timing

ACTION > Foundation help run the community effort to get awareness

  *   * blog posts

  *   * community speaking

  *   * speaker circuit

  *   * message is "we are doing this for the user" & "process is defined now"

* Calendar to Paris

  *   * Pre-OSCON

  *      * Foundation blog posts to advertise input days < June 20

  *      * Matrix input from Community (2 meetings 25 & 26 of June)

  *   * OSCON

  *      * Board approves Havana Advisory

  *   * Bylaws plan approved

  *   * Refstack Icehouse data collection starts
  * Icehouse Capabilities - August
  * Icehouse Matrix Scored - finished in October

  *     * TC input as part of scoring (Sept)

  *     * User committee review (Sept)
  * Board Meeting before Paris (phone)

  *     * Board approves "Core Definition Process" for Bylaws Change

  *   * Paris

  *      * Board approves Icehouse

  *      * Board approves Juno

  *   * Jan 15 Election

  *   * Bylaws Change

  *   Interop objectives and progress

  *   Timing for Cycle

  *   Schedule Community Meeting (2) to review matrix [blocked until matrix is done]

## Bylaws IPE - DefCore Process

https://etherpad.openstack.org/p/DefCoreBylawsIPE

### Bylaws Language

Current Text:

  *   4.1 (b) The management of the technical matters relating to the OpenStack Project shall be managed by the Technical Committee. The management of the technical matters for the OpenStack Project is designed to be a technical meritocracy. The "OpenStack Project" shall consist of a "Core OpenStack Project," library projects, gating projects and supporting projects. . The Core OpenStack Project means the software modules which are part of an integrated release and for which an OpenStack trademark may be used. The other modules which are part of the OpenStack Project, but not the Core OpenStack Project may not be identified using the OpenStack trademark except when distributed with the Core OpenStack Project. The role of the Board of Directors in the management of the OpenStack Project and the Core OpenStack Project are set forth in Section 4.13. On formation of the Foundation, the Core OpenStack Project is the Block Storage, Compute, Dashboard, Identity Service, Image Service, Networking, and Object Storage modules. The Secretary shall maintain a list of the modules in the Core OpenStack Project which shall be posted on the Foundation's website.


  *   4.13 (b) The Technical Committee shall have the authority to determine the modules for addition, combination, split or deletion from the OpenStack Project except for modules of the Core OpenStack Project (as defined in Section 4.1(b) above) which shall be managed as provided below. For modules of the Core OpenStack Project, the Technical Committee may recommend to the Board of Directors the modules for addition, combination, split or deletion from the Core OpenStack Project. Except as provided below, the Board of Directors shall consider only those additions, combinations, splits or deletions that are recommended by the Technical Committee, but shall have the sole authority to approve or reject such additions, combinations, splits and deletions from the Core OpenStack Project. If any software in the Core OpenStack Project is (i) subject to an injunction or other court order which would subject the distributors or users of such software to liability for intellectual property infringement or misappropriation or (ii) the majority of the Board of Directors believes that such an order is reasonably likely, the Board of Directors shall give notice to the chair of the Technical Committee of the issue. If the Technical Committee does not take reasonable steps to mitigate the risk (such as ceasing distribution of such software or modifying such software to make it non-infringing) as determined by the Board of Directors within thirty (30) days of the receipt of such notice, the Board of Directors may waive the requirement in the Trademark Policy or otherwise to include such software in a distribution in order to use the OpenStack trademarks.

  *

  *   9.2 Special Votes.

  *   (a) In addition to the vote of the Board of Directors as provided in Section 9.1, the amendment of the following Sections or Appendices requires an affirmative vote of a majority of the Individual Members voting as provided in Article III, but only if at least 25% of the Individual Members vote: Sections 3.2, 3.5(a), 3.6 (as it relates to Individual Members), 3.9(a), 4.2(d), 4.4 (as it relates to Individual Members), 9.2(a) and the Individual Member Policy.(b) In addition to the vote of the Board of Directors as provided in Section 9.1, the amendment of the following Sections or Appendices requires an affirmative vote of a majority of the Gold Members voting as provided in Article III: Sections 3.3, 3.5(b), 3.6 (as it relates to Gold Members), 3.9(b), 4.2(c), 4.4 (as it relates to Gold Members), 9.2(b) and the Gold Member Policy.(c) In addition to the vote of the Board of Directors as provided in Section 9.1, the amendment of the following Sections or Appendices requires an affirmative vote of a majority of the Platinum Members as provided in Article III: Sections 3.6 (as it relates to Platinum Members), 3.9(c), 4.2(b), 4.4 (as it relates to Platinum Members), 9.2(c) and the Platinum Member Policy.

  *   (d) In addition to the vote of the Board of Directors as provided in Section 9.1, the amendment of the following Sections requires an affirmative vote of (i) two-thirds of the Gold Members, (ii) two-thirds of the Platinum Members, and (iii) a majority of the Individual Members voting (but only if at least 25% of the Individual Members vote at an annual or special meeting): Article II (not including the Appendices referenced in Article II), Sections 4.1, 4.2(a), 4.9, 4.10, 4.11, 4.13, 4.17, 4.20, 7.1, 7.2, 7.3, 7.4 (except that approval of an amendment to Section 7.4 requires a two thirds vote of the Board of Directors instead of the vote provided in Section 9.1), 9.2(d), and the Technical Committee Member Policy. However, the Board of Directors may by majority vote, amend the Trademark Policy prior to January 31, 2013 to establish testing and certification requirements for the use of the trademarks owned by the Foundation in connection with the use of the Core OpenStack Project. The amendment of Sections 3.4, 3.5(c), 3.7, and 3.10, as they apply to a particular class, requires an affirmative vote as follows for a particular class (i) two-thirds of the Gold Members, (ii) two-thirds of the Platinum Members, or (iii) a majority of the Individual Members voting (but only if at least 25% of the Individual Members vote at an annual or special meeting).

1) We are removing
  1a) "core definition by projects" from the bylaws
  1b) Technical committee recommendation of parts of OpenStack as "core"
2) We are replacing it with a capability & test focused defined process that is governed by the Board and changed by a simple majority vote of the Board (not community)
3) We are not changing the Technical committee's management of the "integrated release" of which core is a subset
4) We are not adding "designated sections" to the bylaws (so there are not required code parts)
5) Board must approve changes to the Foundation trademark policy - policy would be another defined process
     not for everyone.

ACTION > Review IPE w/ TC

## PROCESS FOR DEFINITION OF CORE

Today's core definitions are tightly coupled to individual projects.
Tomorrow's core definitions will be individual capabilities of different projects.

DEFINITION: Certification to use the OpenStack mark requires passing tests of capabilities, and including designated sections of code.

A. TESTS

  1.  All tempest tests for OpenStack must be grouped into capabilities.

  1.  Tests that don't pass in trunk (or that can only be passed by certain configurations) can be "flagged" by DefCore, and will be skipped.

  1.  These capabilities are scored by the DefCore committee during each release cycle, using board-approved criteria.

  1.  The board defines the criteria for this scoring and may adjust relative importance of criteria with each release.

  1.  The board defines the cut-off score for determining that a capability is core

  1.  Capabilities that surpass the cutoff score are considered "core capabilities".

  1.  In each core capability, all non-flagged tests must pass in any OpenStack product or service that uses the mark

  1.  Capabilities will not be depricated without with at least 1 release notice

B. DESIGNATED SECTIONS

  1.  The PTL of each project will identify sections of code to be "designated" which must be used in OpenStack products and services.

  1.  The TC will ratify these designated sections.

  1.  Designated sections only apply to projects that have some core capabilities.

  1.  Designated sections will not be increased without at least 1 release notice

C. ACTIVITIES(Work Flow?)

  1.  Criteria changes are managed by the DefCore committee and ratified by Board vote and posted on the OpenStack Wiki

  1.  Designated Sections changes are managed by the TC as Gerrit proposals

  1.  Capabilities changes are managed via Gerrit reviews

  1.  all tests are categorized into a capability by the PTL through Gerrit patch of the JSON file

  1.  tests are flagged-to-skip by approval of patches to the refstack json (by the Board as a slate vote)

  1.  Tests are unflagged through the same mechanism (by action of the DefCore committee)

  1.  DefCore changes to flagged to skip tests, criteria are to be ratified by the Board

D. GRIEVANCES

  1.  Test Issues > via Gerrit to Capabilities list

  1.  Critiera Issues > via DefCore mailing list & meetings

  1.  Designated Sections > via TC processes

  1.  Compliance Violations > same as trademark issues ACTION> SETUP trademark at openstack.org

  1.  Capabilities scores -> Community forums and roundtables during matrix review / also through Gerrit

E. PUBLISHING

  1.  The DefCore committee will manage content of a community website (currently at http://RefStack.org)<http://refstack.org%29/> and publish:

  1.  The DefCore principles

  1.  The current and historical scoring criteria

  1.  The categorization of tests into capabilities

  1.  The current and historical scored matrixes of capabilities

  1.  The scorecards of licensed products and services

  1.  Only "pass" tests will be reported in the process

  1.  OpenStack retains the right to be the official source of the results, and will copyright the RefStack and DefCore materials to support this.

F. TIMELINES:

  1.  Vendors will anonymously self-certify their products and services under the DefCore program for the Juno release.

  1.  In the "K" release, the Vendor's scorecards will be made public on the RefStack website.

  1.  Process modifications will be applied to future releases.

ACTION > Create a flow chart
ACTION > Circulate to Board
ACTION > Discuss Api review more broadly, consider an RFP (include test parameters?)


Rob
______________________________
Rob Hirschfeld
Sr. Distinguished Cloud Solution Architect
Dell | Cloud Edge, Data Center Solutions
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140620/d9bcbd7e/attachment-0001.html>