Open Stack

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.

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

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






-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121116/72b4e794/attachment.bin>