Open Stack

Board & TC,



We has a meeting on 7/15 to continue the dialog that I felt was highly productive and incorporated the feedback you'd provided on the email lists.  As a consequence, we've improved the language and expanded the number of positions to 12.   We tried to add new at the bottom but there were edits to every position during discussion.



I'm including the positions below, but I encourage you to review on the etherpad, fix typos and make adjustments.  Of course, dialog on email is welcome too!



OSCON Face to Face Discussions are our next step before the next board meeting and expanding to the Community.



* OSCON Wednesday 4PM just before OpenStack birthday party in Expo Hall (watch Twitter for info)

* OSCON Thursday 8PM at Birds of a Feather session (just after the "Distro Smackdown")



Of course, I'm happy to have 1x1 discussions about this too.  I've started a blog series to try an capture the background and process: http://wp.me/pF6d2-CN



Here are the current positions:


1.     SINGLE API / MULTIPLE IMPLEMENTATION MODEL (aka PLUG-IN) DESIRED FOR PROJECTS
1.     OpenStack will require an open source reference base plug-in implementation for projects (if not part of OpenStack, license model for reference plug-in must be compatible).
2.     Definition of a plug-in: alternate backend implementations with a common API framework that uses common _code_ to implement the API
3.     This expects that projects (where technically feasible) are expected to implement a plug-in architecture.
4.     This is already in place for several projects and addresses around ecosystem support, enabling innovation
5.     Reference plug-ins are, by definition, the complete capability set.  It is not acceptable to have "core" features that are not functional in the reference plug-in
2.     API EXTENSION MODEL EXPECTED  FOR PROJECTS
1.     OpenStack will follow architectures patterns that enable API extensions.
2.     This will enable plug-ins to offer innovative or differentiated features without forcing changes to the reference plug-in implementation
3.     This will enable the reference to expand without forcing other plug-ins to match all features and recertify
3.     COMMUNITY MAINTAINED TESTS (TEMPEST?) USED AS BASIS FOR OPENSTACK MARK
1.     Vendor OpenStack implementations must achieve 100% of must-have coverage?
2.     Implemented tests can be flagged as may-have requires list  [Joshua McKenty]
3.     Certifiers will be required to disclose their testing gaps.
4.     This will put a lot of pressure on the Tempest project
5.     Maintenance of the testing suite to become a core Foundation responsibility.  This may require additional resources
4.     VALIDIBLE REMOTE SELF-CERTIFICATION (ON DEMAND TESTING)
1.     Plug-in certification is driven by Tempest self-certification model
2.     Self-certifiers are required to publish their results
3.     Self-certified are required to publish enough information that a 3rd party could build the reference implementation to pass the tests.
4.     Self-certified must include the operating systems that have been certified
5.     It is prefered for self-certified implementation to reference an OpenStack reference architecture "flavor" instead of defining their own reference.  (a way to publish and agree on flavors is needed)
6.     The Foundation needs to define a mechanism of dispute resolution. (A trust but verify model)
5.      SUBSTITUTE PLUG-IN IMPLEMENTATIONS OK
1.     If a vendor plug-in passes all relevant tests then it can be considered a full substitute for the reference plug-in
2.     If a vendor plug-in does NOT pass all relevant test then the vendor is required to include the open source reference in the implementation.
3.     From the may have pick list - must have all must haves. Must haves are 'core' See number 12
6.     TESTING CERTIFICATION BY PLUG-IN IF >1 REFERENCE PLUG-IN
1.     Looking forward to having multiple reference plug-ins, Tempest may to distinguish between multiple reference plug-ins.
2.     You can pass certification by passing just one reference test suite + the project tests.
3.     The objective for this position is to allow for future OpenStack functions that requires breaking changes to implementation
7.     OPENSTACK DEFINITIONS APPLY EQUALLY TO ALL DEPLOYMENTS
1.     There should not be multiple definitions of OpenStack depending on the operator (public, private, community, etc)
2.     While expected that each deployement is identifical, the differences must be quantifiable.
8.     DISCOVERABLITY OF COMPABILITY (VARIATION IS OK)
1.     Implementations and products are allowed to have variation based on publication of compatabliity
2.     Consumers must have a way to determine how the system is different from reference (posted, discovered, etc)
3.     Testing must respond in an appropriate way on BOTH pass and fail (the wrong return rejects the entire suite)
4.     We are NOT stating which projects are required in this position
9.     MUST USE OPENSTACK API IMPLEMENTATION CODE
1.     Implementation's claiming the OpenStack Mark must use the API  framework code
2.     You are not OpenStack, if you pass all the tests but do not use the API framework
3.     This prevents people from using the API without joining the community
4.     This also surfaces bit-rot in "PLUGINS" to the larger community
5.     This behavior improves interoperability because there is more shared code between implementation
10.   API CONSUMERS SELF-CERTIFY AGAINST THE REFERENCE IMPLEMENTATION
1.     As an ecosystem partner, you have a need to make a "works against OpenStack" statement that is supportable
2.     API consumer can claim working against the OpenStack API if it works against any implementation passing all the "must have" tests(YES)
3.     API consumers can state they are working against the OpenStack API with some "may have" items as requirements
4.     API consumers are expected to write tests that validate their required behaviors (submitted as "may have" tests)
5.     The TC will decide which tests are elevated from may-have to must-have
11.   THE "MUST-HAVE" TESTS DEFINE "OPENSTACK CORE"
1.     We are NOT defining which items are on the list in this effort, just making the position that it is how we will define core
2.     May-have tests include items in the integrated release, but which are not core.
3.     We will have a process by which tests are elevated from may to must lists
4.     Potentially: the User Committee will nominate tests that elevated to the board
5.     Must haves - must comply with the Core criteria defined from the IncUp committee results
6.     The OpenStack board owns the responsibility to define 'core' - to approve 'musts'
7.     Projects in Incubation or pre-Incubation are not to be included in the 'may' list
12. SPIDER AND CORE DEFINE A SUBSET OF ALL OPENSTACK TRADEMARKS
1.     a. There may be other marks that are managed separately by the foundation, and available for the platform ecosystem as per the Boards discretion
2.     "OpenStack API Compatible " MARK NOT GRANTED
3.     This topic is difficult to close at this time and requires a breath of testing that does not yet exist
4.     This is a temporary working position that may be revisited





Rob

______________________________

Rob Hirschfeld

Sr. Distinguished Cloud Solution Architect

Dell | Cloud Edge, Data Center Solutions

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/20130723/2b2d9e69/attachment-0001.html>