Open Stack

I think “Core Capability” works, provided we have a good clear definition for the word that makes it clear this is meant to be used in the context of technical capabilities commercial products are expected to include if they wish to license the OpenStack marks.  Maybe it’s that simple:

Core Capability:  A capability all commercial products are expected to include when marketed as “OpenStack”, to ensure interoperability between such products, which will be implemented via requirements in trademark licenses granted by the foundation.

This should make it clear that the new use of “core” is all about commercial implementations/products nothing else, superseding the old concept of “core” which was more associated with projects and how they are managed in the community.  Is that a fair statement?


On Apr 30, 2014, at 10:22 PM, <Rob_Hirschfeld at Dell.com> <Rob_Hirschfeld at Dell.com> wrote:

> 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 process before and we’ve put them into application and discussed them with the community.  The feedback was simple: tl;dr.  You’ve got the right direction but make it simpler!
> <image001.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/6698d4d8/attachment-0001.html>