Open Stack

The OpenStack Mission is to:

To produce the ubiquitous OpenSource Cloud Computing platform that will
meet the needs of public and private clouds regardless of size, by being
simple to implement and massively scalable.

IMHO the operative (action) word is "produce."  This is why I agree with
Monty that it is critical that if we start somewhere, it should be with a
program based on people running the code, who have a vested interest in the
code's continual evolution and survival.  If we take our eye of of that it
could invite fragmentation and dilution of any meaning for "what is
openstack".

That said, it seems to me that technically speaking, we might only need 1
set of tests that could feed the two distinct programs being described
("openstack cloud" and "compatible").  So there might be to two
(marketing/business/logo) *programs* with unique requirements other than
testing, but with one test suite.

Therefore, IMHO, the best place to start is with the development of the
test itself while continuing to discuss the ways in which the results might
be applied to two distinct (logo) *prorgrams*.  Now I understand that you
cant develop a test in the absence of requirements such as which projects
to include, but we could probably come up with a sensible starting point
and add additional coverage over time (increasing test coverage not
necessarily implying that each must pass to qualify for a specific program).







On Thu, Oct 31, 2013 at 9:58 AM, Mark McLoughlin <markmc at redhat.com> wrote:

> On Thu, 2013-10-31 at 14:52 +0000, Mark McLoughlin wrote:
> > On Thu, 2013-10-31 at 07:41 -0700, Monty Taylor wrote:
> > > There is a VERY specific and strong reason why this is not the
> approach,
> > > and that's because it disincentivies people from working on OpenStack
> > > itself. We already have the problem with Neutron where not enough
> > > companies are working on the core of neutron because they're all only
> > > working on their vendor plugins. If OpenStack all of a sudden became a
> > > set of interfaces, then the goal of an Open cloud would, I'm pretty
> > > certain, become lost.
> >
> > Rob talks about using having three tools - our culture, our velocity and
> > our trademark. The first two could be as effective at having people
> > choose to use OpenStack itself rather than a compatible implementation
> > of its interfaces.
> >
> > I could see us having two trademark programs "OpenStack Cloud" - where
> > you know that the provider is running a "faithful implementation" of
> > OpenStack code - and "OpenStack Compatible Cloud" - where you just know
> > the provider is compatible with the interfaces.
> >
> > I'd see having "OpenStack Compatible Cloud" as the first priority.
> >
> > If we can figure out how to build a sane "OpenStack Cloud" program in
> > short order, then awesome. But it shouldn't hold back the first program.
>
> Oh, and to be clear - if it did happen this way, I'd quite happily
> deprecate the "OpenStack Compatible Cloud" program once we have the
> "OpenStack Cloud" program in place.
>
> Or maybe there's only one program and the "use OpenStack code"
> requirement gets added in the future.
>
> So, I agree that it is not a long-term goal for OpenStack to be a
> standards organization encouraging multiple alternate implementations of
> its APIs.
>
> But we do need to get moving on encouraging interoperability between
> public clouds, even if that means making a short term tactical decision
> that we don't need to require they use OpenStack code for everything.
>
> Mark.
>
>
> _______________________________________________
> Foundation mailing list
> Foundation at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20131031/017b29ee/attachment-0001.html>