Open Stack

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