Open Stack

On Fri, Nov 9, 2012 at 9:23 AM, Zane Bitter <zbitter at redhat.com> wrote:

> On 08/11/12 06:34, John Dickinson wrote:
>
>> OpenStack Core should be defined as IaaS, and the "batteries-included"
>> parts should be part of the ecosystem but not part of core.
>>
>
> I'd like to address the idea that has come up several times this week that
> "ecosystem" projects are competing on the merits of their code, and that by
> promoting a particular project to core OpenStack would be engaged in
> prematurely "picking winners" and therefore distorting the free competition
> between projects.
>
> That's not how I see it: Open Source projects compete on the strength of
> their communities, not the merits of their code. A good community can fix
> just about any code, but code can never save a weak community. And it seems
> to me that the TC absolutely is qualified to make judgements about this.
>
> In my opinion, if a group has:
>  * A problem that is common to a substantial proportion of OpenStack users;
>  * A solution to that problem in the form of working (if incomplete) code;
>  * A proven commitment to do things the OpenStack way; and
>  * A record of collaboration with the larger OpenStack community
>
> then there *needs* to be a place for them in OpenStack proper, not just as
> a Related project. Because otherwise we will continue to see these
> important problems being solved piecemeal by proprietary projects; or
> projects that are not developed in consultation with the community that are
> then dropped on us out of the blue, written in Java or having problematic
> dependencies or any number of other fundamental architectural problems that
> would have been ironed out right at the beginning if development had
> happened in the open. That situation is bad for developers (who have to
> deal with a balkanised ecosystem), bad for providers (who have the expense
> of maintaining their own individual implementations), and especially bad
> for users (for all the reasons that Monty has pointed out elsewhere in this
> thread). It would result in OpenStack being much less relevant than it
> ought to be.
>
> Now, the definition of "Core" is currently linked closely to trademarks.
> So if you prefer to define "Core" as Nova + Swift + Quantum with everything
> else as an Official but not Core project then that's fine by me (although I
> personally find the distinction pointless). Projects like Heat or Horizon
> exist only to work with other core projects, and are unlikely to be
> distributed independently. But I am completely opposed to banishing
> everything else to the non-official "ecosystem". The ecosystem, of course,
> has its place, but its place is specialised functionality and plugins that
> allow providers to use different back-ends without breaking API
> compatibility for users, not as a catch-all for all the things that are an
> essential part of a modern IaaS offering but aren't Compute, Object Storage
> or Networking.
>
> cheers,
> Zane.
>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>

Seems to me that core should be defined as the base components/projects
needed to run an OpenStack cloud.  In my opinion that would be Compute,
Networking and Storage.  Those would be the base categories, by no means is
that the sum of the the parts that make up OpenStack but it's the base, the
things with which you can't really stand up a basic cloud architecture
without.

If every single feature/project that is useful, and well written/managed is
added to that core list you end up with... well, confusion along with a
serious manageability issue.  The reality is that one piece of feed-back I
receive from folks trying to run OpenStack in their business is that it's
already a bit of a challenge to manage all of the different pieces, to
understand exactly what each does, what's actually required and how they
all interact.  Continuing to add "core" projects based alone on the quality
of the code and it's usefulness seems like we'd be compounding that issue.

There of course would need to be exceptions to this, for example a project
that adds to the existing core projects in such a way that they end up
relying upon it to provide their functionality.  I think a good example of
this would be Keystone, Identity management wasn't included in my original
definition because I don't think it's required to just stand up a cloud and
have base functionality.  That being said it is a critical component, and
has in essence been designed in to all of the core OpenStack projects.
 It's the base reference implementation, whether others use it, something
else or nothing it's been essential in our designs and infrastructure.

So how would another project become core?  Well, that would depend on
whether they offered some base functionality that was "required" to stand
up a cloud.  Or... if the current core projects end up relying on them
heavily enough that they need said projects in order to provide their full
capability.  By keeping a "smaller" core team, those core teams can work
together and synchronize on the use of new projects, as opposed to having
the core projects continue to grow to a point where it's unmanageable.

The bottom line is that in my opinion the word "core" has a definition ("the
 central, innermost, or most essential part of something"), that should be
the definition we use for OpenStack as well.  How to deal with a new
category and what that looks like is another task, but maybe it would be
more productive to first answer the question of what is core.


John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121109/553cf27e/attachment.html>