Open Stack

I assume RDO is an example of a 'noncommercial product'
http://openstack.redhat.com/Main_Page


On Thu, May 01, 2014 at 06:56:59PM +0000, Auld, Will wrote:
> I don’t really have anything in mind. However, anything and everything that
> might be considered as a candidate for a granted a license should be included.
> 
>  
> 
> Thanks,
> 
>  
> 
> Will
> 
>  
> 
> From: Mark Collier [mailto:mark at openstack.org]
> Sent: Thursday, May 01, 2014 11:44 AM
> To: Auld, Will
> Cc: Rob_Hirschfeld at Dell.com; Defcore-committee at lists.openstack.org
> Subject: Re: [OpenStack-DefCore] Please review - lexicon, Public APIs only &
> capabilities definition text
> 
>  
> 
> What would be an example of a non commercial product?
> 
>  
> 
>  
> 
> On May 1, 2014, at 1:31 PM, Auld, Will <will.auld at intel.com> wrote:
> 
> 
> 
> I’m having a little trouble with “Core Capability” and “Capability.”
> 
>  
> 
> I like Mark’s definition but want it to also say how we know whether specific
> items are part  of the “core capability.” For example we might modify Mark’s
> definition as:
> 
>  
> 
> Core Capability:  A capability all [S:commercial:S] 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. The requirements will include both “Designated
> Sections” and “Capabilities”  defined by the technical committee.
> 
>  
> 
> I think this should apply to any product, commercial or otherwise, for which we
> grant a license.
> 
>  
> 
> As for my problem with “Capability,” I think it should be more about the
> functionality than the tests:
> 
>  
> 
> Capability – the functionality ensured by 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)
> 
>  
> 
> Thanks,
> 
>  
> 
> Will
> 
>  
> 
> From: Mark Collier [mailto:mark at openstack.org] 
> Sent: Thursday, May 01, 2014 10:33 AM
> To: Rob_Hirschfeld at Dell.com
> Cc: Defcore-committee at lists.openstack.org
> Subject: Re: [OpenStack-DefCore] Please review - lexicon, Public APIs only &
> capabilities definition text
> 
>  
> 
> 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
> 
>  
> 

> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee