[openstack-tc] Reminder: DefCore Meeting Tuesday 1:30 PST + notes from Critieria Subcommittee

Rob_Hirschfeld at Dell.com Rob_Hirschfeld at Dell.com
Fri Dec 13 14:47:37 UTC 2013


All,

I'm sending this to the broader group because there is so much overlap and I know there is broad interest.

Here's the info for our next meeting

Notes to be on: https://etherpad.openstack.org/p/DefCoreElephant.2

Share Info: Join the meeting: https://join.me/486-909-516 On PC or Mac, use any browser with Flash. Nothing to download. On a phone or tablet, launch the join.me app and enter meeting code: 486-909-516

Join the audio conference: No matter how you join the conference, everyone will be on the same audio call.

By phone: 1) Dial +1.415.464.6999 (United States) Dialing from another country? Check our international numbers:http://help.join.me/knowledgebase/articles/149448-does-join-me-offer-international-conference-number 2) Enter conference ID: 486-909-516#

Agenda:
·         OIN impacts from Core/Commons definition
·         How to figure out where we have gaps in Tempest coverage
·         Program vs Project Definition Discussion
·         Define a process by which programs are nominated for use with the mark
·         by which tests certified for use with the mark
·         test list is vetted and approved by the board
Subcommittee Notes from https://etherpad.openstack.org/p/DefCoreTestCriteria

MEETING 1: Interactive Discussion Scheduled for 12/10 @ 9:30 PDT
·
·         Attendees: Nick, Mark Mc, Josh, Lew, Troy, Sean, Monty, Joshua, Alan, Monty, Rob H
·         Summary: We determined 7 critiera that are concensus, 2 anti-criteria and 3 that require additional debate

MEETING 2:Interactive Discussion Scheduled for 12/30 @ 1:30pm PST

·         https://join.me/860-474-362
·         1) Dial +1.860.970.0010 (United States) Dialing from another country? Non-US http://help.join.me/knowledgebase/articles/149448-does-join-me-offer-international-conference-number
·         2) Enter conference ID: 860-474-362#
·
Agenda:
    * weighting approach (15 mins)
    * re-open/review discussion existing 7+2 critiera (15 minutes)
    * additional criteria (30 mins)
    * ugly contentious items that we identified
    * exit meeting w/ usable criteria!

## Critieria

AGREED-UPON CRITERIA:
----------------------

Criteria for evaluating proposed required criteria/passing tests for the first revision/iteration
 These tests are meant to define a core set of capabilities that application developers can count on to be present in OpenStack distributions and deployments

1. Test is required stable for >2 releases (because things leaving core are bad)

 *   the least number/amount of must pass tests as possible (due to above)
§  but noting that the number will increase over time

 *   least amount of change from current requirements as possible (nova, swift 2 versions)

 *   (Acknowledge that deprecation is punted for now, but can be executed by TC)
2. Where the code has an extension framework, there should be parity in capability across extensions

 *   Test is not configuration specific
3. Capability being tested is Service Discoverable (can be found in Keystone and via service introspection) - MONTY TO FIX WORDING around REST/DOCS, etc.

 *   Nearly core or "compatible" clouds need to be introspected to see what's missing

 *   Not clear at this point if it's project or capability level enforced.  Perhaps for Elephant it's project but it should move to capability for later
4. Candidates are widely used capabilities
·         4A favor capabilities that are supported by multiple public cloud providers and private cloud products

 *   Allow the committee to use expert judgement to promote capabilities that need to resolve the "chicken-and-egg"

 *   Goals are both diversity and quantity of users

 *   (there's a follow-up about how to weight this input)
·         4B. Should be included if supported by common tools
·         4C. Should be included if part of common libraries (Fog, JCloud,e tc)
5. Test capabilities that are required by other must-pass tests and/or depended on by many other capabilities
6. Should reflect future technical direction (from the project technical teams and the TC)

 *   Deprecated capabilities would be excluded (or phased out)

 *   This could potentially become a "stick" if used incorrectly because we could force capabilities
7. Should be well documented, particularly the expected behavior.

 *   includes the technical references for others in the project as well as documentation for the users and or developers accessing the feature or functionality
8.... stay tuned for more episodes of "THE CORE IS RIGHT"

REJECTED CRITERIA:
------------------
·         Is not legally encumbered (terrifyingly complicated to implement)

 *   is known to not likely be
·         No Veto (no group is given the abilty to veto a test as a candidate)


Non-Concensus CRITERIA for DISCUSSION:
-------------------------------

* Tests will not be considered for projects without any extension framework
* Candidates favor capabilities that users cannot implement if given the presence of other capabilities
·         consider the pain to users if a cloud doesn't have the capability - not so much pain if they can run it themselves
* Tests do not require administrative rights


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/openstack-tc/attachments/20131213/52d79cda/attachment-0001.html>


More information about the OpenStack-TC mailing list