Open Stack

On Fri, Nov 16, 2012 at 2:06 PM, John Dickinson <me at not.mn> wrote:

>
> On Nov 16, 2012, at 1:57 AM, Thierry Carrez <thierry at openstack.org> wrote:
>
> > John Dickinson wrote:
> >> Here's an alternative OpenStack Core project definition:
> >>
> >> OpenStack Core projects:
> >> 1) provide the API and implementation for compute, storage, or network
> infrastructure-as-a-service
> >> 2) may be deployed independently
> >> 3) cooperate to provide a unified OpenStack release
> >> 4) must be scalable from small private clouds to large public service
> providers
> >
> > So, this is a definition of "core", but it doesn't really address how
> > incubation would work in this case, and how we would transition to that
> > model, which is part of the "direction" we have to define. In particular:
> >
> > - How much say should the TC have over "core" projects approval in your
> > view ?
>
> No change from the current bylaws: TC recommends projects, BoD approves
>
> > - Would "incubation" be reserved to your "core" projects ?
>
> Incubation would be a path to being included in OpenStack (in any
> category). As I discuss below, and as I've mentioned before, I think what
> gets included in OpenStack should be restrictive.
>
> > - What would we do with TC-supported incubated core projects that are
> > finally refused by the BoD after months of incubation ?
>
> Is this a realistic concern? TC/BoD communication can't be a "throw it
> over the wall" thing. If this were to ever happen (and I find that
> unlikely), the pressing concern would be to adjust both the assumptions of
> and communication between the TC and BoD.
>

We have this situation already. Ceilometer was approved for incubation, but
it's far from clear that it will become a "core" project. AFAICT, there
isn't a clear definition of what would happen to the project if the BoD
rejects an application to be added to core.


>
> > - What category would we demote current non-IaaS core projects (Horizon,
> > Keystone) and incubated projects (Ceilometer, Heat) to ?
>
> This question is extremely poorly worded. A project in "core" or not is
> not a status symbol. There is not a "demotion". These projects that you
> have listed are working very hard to solve important problems in the
> OpenStack ecosystem. Implying that, even within the OpenStack project
> categories, there are ranks is very dangerous. At best it implies a lack of
> focus and at worse it leads to fractures in the community.
>
> Projects that solve IaaS problems may be categorized as "core" (and thus
> have extra trademark or other restrictions). Projects that solve
> project-wide problems (eg docs, CI, and QA) may be categorized as something
> non-core, but this in no way implies that they are lesser in any way. These
> parts of OpenStack are vital to OpenStack's success.
>
> Projects that do not fit within these categories should not be part of
> OpenStack. This also in no way implies that they are lesser in any way, but
> only that OpenStack's infrastructure and focus does not include them. This
> is similar to the rejection of Scalr's application to be included in
> OpenStack.
>

Regardless of the choice of words, the question remains: What is the "next
state" for a project that enters incubation and then is not moved to
core? Incubation is a temporary state. If a project doesn't move to core,
what does happen? Is the level of support granted during incubation then
revoked?


>
> > - Would that category still be granted additional common
> > Summit/QA/Doc/RelMgt/CI resources compared to random ecosystem projects ?
>
> The benefits that being an OpenStack project brings are marketing and a
> dedicated track at the summits. There is some benefit of the
> QA/Doc/RelMgt/CI infrastructure that OpenStack has (mostly around "it
> exists" and sharing the burden between companies), but these are not tools
> exclusive to Openstack. Many other projects are quite successful without
> OpenStack's help in these areas.


> All projects that are managed by OpenStack (collectively the "OpenStack
> projects") would have access to and be included in the summit, QA, docs,
> release management, and CI tools.
>

> >
> > Could you expand your proposal to address those questions, so that this
> > can be considered a complete alternate "direction" that we can choose
> > from in the next meeting ?
>
>
> I like the current bylaws description of OpenStack projects, and I don't
> think it needs to be changed.
>
> I agree with Mark that incubation is a path to be "included in OpenStack"
> or "not included in OpenStack". I also agree that the BoD, not the TC, is
> the group concerned with the OpenStack mark. This is what the bylaws
> currently say, and doesn't seem to be contentious.
>
> Where I seemingly disagree with others is that the scope of OpenStack
> projects should be limited to IaaS projects (as defined in my other email
> and quoted above) and the necessary pieces for managing and delivering
> those projects (eg docs, CI, etc).


>
> --John
>
>
>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121116/18e2f511/attachment.html>