Open Stack

This was my biggest concern as well, and I agree that "reference implementation" is much better.

One of my other concerns is coding requirements put onto a particular project (ie Tempest). In an open-source development model, this cannot be coerced, so what is the proposal for how to actually get people to dedicate time to adding functionality? In an extreme sense, what's the incentive to go beyond the following implementation?

def test_is_openstack(self, *a, **kw):
    """Returns True if the target cluster conforms to the OpenStack brand"""
    return True

It would certainly reduce the number if things I need to spend energy thinking about.


I will not be able to attend either meeting today. Thierry, you and I need to work together tomorrow on 1.9.1.

--John


On Jul 30, 2013, at 6:00 AM, Rob_Hirschfeld at Dell.com wrote:

> +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)
> 
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20130730/77fe815a/attachment.pgp>