Open Stack

+1  after discussions at OSCON this matches consensus and improves clarity. 


----- Original Message -----
From: Thierry Carrez [mailto:thierry at openstack.org]
Sent: Tuesday, July 30, 2013 03:57 AM
To: openstack-tc at lists.openstack.org <openstack-tc at lists.openstack.org>
Cc: Hirschfeld, Rob
Subject: Re: [openstack-tc] Update on Spider "What is Core" Discussion > F2F meetings at OSCON

Mark Washenberger wrote:
> 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.

I don't think the key issue with the current wording is that it reduces
the definition of "plug-in"... I think the problem is it uses the word
"plug-in" to designate what ends up being an alternative implementation
model.

"Plug-in" is one of multiple technical strategies to implement optional
code paths (to replace or extend functionality). As you mention, plug-in
techniques could be used in other parts of the software that have
nothing to do with alternative implementation (could be used to
implement add-ons as well).

I would rather use "reference implementation" and "alternative
implementation" rather than the current "plug-in" wording. It would
remove the ambiguity and avoid bleeding into technical territory:

"""
SINGLE API / MULTIPLE IMPLEMENTATION MODEL DESIRED FOR PROJECTS

1. OpenStack will require an open source reference implementation for
projects (if not part of OpenStack, license model for reference
implementation must be compatible).

2. Alternate backend implementations must use the common API framework
by using common _code_ to implement the API

3. This expects that projects (where technically feasible) are expected
to implement a way to plug in alternate implementations.

[...]

5. Reference implementations are, by definition, the complete capability
set.  It is not acceptable to have "core" features that are not
functional in the reference implementation

[...]

2. This will enable alternate implementations to offer innovative or
differentiated features without forcing changes to the reference
implementation

3. This will enable the reference to expand without forcing alternatives
to match all features and recertify
"""

etc.

-- 
Thierry Carrez (ttx)