Open Stack

I am concerned that the wording of item #1 in this list is legislating from
current practice, and in effect would stifle some important types of
innovation and improvement in our architecture.

I'm struggling a bit to come up with an improved alternative, but I think
the issue is essentially with the definition of a plugin as residing behind
common code that implements an API. In particular, I don't think plugins
necessarily live behind APIs, for example, I could imagine a plugin
implementing a periodic cleanup task on a worker node. I can also imagine
an application or framework that would enable plugins to directly expose
HTTP api routes--in such a case there would be no common code implementing
the API controller in the common sense of the term.

Can we use a more generic definition of plugin? To me, a plugin is a
library component that implements a defined interface and can be loaded
into an existing application via that application's proper configuration
settings. That definition doesn't restrict the sense of a plugin to any
specific technological flavor.



On Tue, Jul 23, 2013 at 6:53 AM, <Rob_Hirschfeld at dell.com> wrote:

> 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 ****
>
> ** **
>
> ** **
>
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20130729/631293f1/attachment-0001.html>