Open Stack

All,

We're getting into crunch time for DefCore!  We need to get the TC & PTLs engaged to help score the last criteria.

At the last meeting, we put that on hold to figure out some lexicon.  Please review and raise issues if you have any:

Lexicon:


·         Core Capability - this is THE REAL DEAL - core capabilities are the definition of core.  OpenStack products demonstration that they work for the core capabilities.   We believe it's important to use the word "core" here and not introduce new terms like "required" "baseline" or "essential."

·         Capability Selection  Matrix - this is how we pick core capabilities by scoring them with the selection criteria

·         Selection Criteria - this is one of 12 factors considered in selecting core capabilities. (see text below)

·         Designated Section - a part of the code that the OpenStack technical community has identified as required to be implemented.

·         Capability - a set of tests collected into a group as defined by the technical community (the DefCore committee has made preliminary assignments to start the process)

·         DefCore - the board committee that oversees that core capability selection process for each release and other items related to the commercial brand.

Also, I'd like to made a quick decision > PUBLIC APIs ONLY.  I was looking at the criteria and realized that non-admin trumps everything.  I believe that we just need to accept that Core is Public API only because that's required for interop.  Admin tests are great but will not be core.

Finally, here's an updated description of the Capabilities Scoring that Josh and I have worked out (WITH GRAPHICS!)

DefCore Core Capabilities Selection Criteria SIMPLIFIED -> how we are picking Core



I've posted about the early DefCore core capabilities selection<http://robhirschfeld.com/2014/01/07/defcore-critieria/> process before and we've put them into application and discussed them with the community<http://robhirschfeld.com/2014/04/11/defcore-road-show/>.  The feedback was simple: tl;dr<http://en.wikipedia.org/wiki/Wikipedia:Too_long;_didn't_read>.  You've got the right direction but make it simpler!

[http://robhirschfeld.files.wordpress.com/2014/04/capabilities_selection2.png?w=584]<http://robhirschfeld.files.wordpress.com/2014/04/capabilities_selection2.png>

So we pulled the 12 criteria into four primary categories:
1.      Usage: the capabilitiy is widely used (Refstack will collect data)
2.      Direction: the capability advances OpenStack technically
3.      Community: the capability builds the OpenStack community experience
4.      System: the capability integrates with other parts of OpenStack

These categories summarize critical values that we want in OpenStack and so make sense to be the primary factors used when we select core capabilies.  While we strive to make the DefCore process objective and quantative, we must recognize that these choices drive community behavior.

With this prespective, let's review the thirteen selection criteria.  To make it easier to cross reference, we've given each criteria a shortened name:

SHOWS PROVEN USAGE
§  "Widely Deployed" Candidates are widely deployed capabilities.  We favor capabilities that are supported by multiple public cloud providers and private cloud products
§  "Used by Tools" Candidates are widely used capabilities:Should be included if supported by common tools (RightScale, Scalr)
§  "Used by Clients" Candidates are widely used capabilities: Should be included if part of common libraries (Fog, Apache jclouds, etc)
Aligns with Technical Direction
§  "Future Direction" Should reflect future technical direction (from the project technical teams and the TC)
§  "Stable" Test is required stable for >2 releases (because things leaving Core are bad)
§  "Complete" Where the code being tested has an designed area of alternate implementation (extension framework) as per the Core Principles, there should be parity in capability tested across extension implementations
PLAYS WELL WITH OTHERS
§  "Discoverable" Capability being tested is Service Discoverable (can be found in Keystone and via service introspection)
§  "Doc'd" Should be well documented, particularly the expected behavior.
§  "Core in Last Release" A test that is a must-pass test should stay a must-pass test (makes must-pass tests sticky release per release)
Takes a System View
§  "Foundation" Test capabilities that are required by other must-pass tests and/or depended on by many other capabilities
§  "Atomic" Capabilities is unique and cannot be build out of other must-pass capabiliies
§  "Proximity" (sometimes called a Test Cluster) selects for Capabilities that are related to Core Capabilities.  This helps ensure that related capabilities are managed together.

Note: The 13th "non-admin" criteria has been removed because Admin APIs cannot be used for interoperability and cannot be considered Core.




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/20140501/efecef36/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 68250 bytes
Desc: image001.png
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140501/efecef36/attachment-0001.png>