Open Stack

Michael / TC,

I think these are great point.  Overall, I think this discussion has outgrown "plug-in" and we're finding that the suggestions of "reference implementation" and "alternate implementation" improve clarity.   I've updated the https://etherpad.openstack.org/Board-2013-SpiderDiscussion for review.

There's a specific position against something that only delivers the APIs without any of the shared implementation code.  So, just passing the tests without deploying OpenStack code would not count as core.  The API compliance issue is out of scope for core but needs to be addressed.

Rob

-----Original Message-----
From: mikalstill at gmail.com [mailto:mikalstill at gmail.com] On Behalf Of Michael Still
Sent: Friday, July 26, 2013 3:06 AM
To: Hirschfeld, Rob
Cc: openstack-tc at lists.openstack.org; foundation-board at lists.openstack.org
Subject: Re: [openstack-tc] Update on Spider "What is Core" Discussion > F2F meetings at OSCON

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

> 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

I want to clarify this section please.

Does the plugin layer we're talking about here side _inside_ the openstack project, or at the openstack projects API boundary?

For example, a plugin inside an openstack project might be the Xen hypervisor driver. If that's the definition we're using then its ok for such a plugin to exist as long as it implements all the right features.

On the other hand, if we're talking about the API layer, then someone could replace nova entirely with their own thing and still call it openstack if it was API compatible.

Clearly, I think the second of these two examples is undesirable, so I'd like to make sure that the first definition of plugin is the one we're using.

> 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.

So we're saying here that a private cloud implementation that does not implement Swift is not "openstack", right? Or for example oVirt might be compatible with glance and swift, but if it doesn't use nova it is not "openstack"?

Thanks,
Michael

--
Rackspace Australia