Open Stack

On Wed, Nov 7, 2012 at 12:13 PM, Russell Bryant <rbryant at redhat.com> wrote:

> On 11/07/2012 12:04 PM, Doug Hellmann wrote:
> >
> >
> > On Wed, Nov 7, 2012 at 11:40 AM, Thierry Carrez <thierry at openstack.org
> > <mailto:thierry at openstack.org>> wrote:
> >
> >     Hi everyone,
> >
> >     Incubation is currently an OpenStack project status that grants a
> >     promising project more access to OpenStack shared resources,
> especially
> >     in the CI, release management and QA space. That status lets the
> >     promising project prove that it is ready to join other official
> >     OpenStack core projects for the next full development cycle.
> >
> >     In the past governance the Project Policy Board was the only decider
> on
> >     Incubation and Core inclusion. With the new governance, the Technical
> >     Committee is still the only decider on Incubation status and still
> >     proposes projects for Core inclusion, but the Board of Directors has
> the
> >     possibility to veto that Core inclusion.
> >
> >     This creates an awkward process where a project could go all the way
> >     through Incubation and be denied Core inclusion at the end of that
> >     process, basically wasting OpenStack resources. We need to evolve the
> >     Incubation process so that the question of whether a project belongs
> in
> >     "Core" is fully resolved as early as possible. And define how a
> project
> >     can enter, grow or exit the incubation process.
> >
> >     This also raises the question of whether "Core" should really be the
> >     only destination of an Incubated project. Which triggers the very
> >     question of what OpenStack Core actually is. For some it's the
> >     collection of OpenStack projects that work well and complement each
> >     other, for others Core should only include the IaaS pieces, for
> others
> >     they should represent the bare minimum you need to implement to be
> able
> >     to be called an "OpenStack Cloud"...
> >
> >
> > It would be healthy to allow the scope of projects managed by the
> > foundation to evolve over time to be broader than IaaS components. If we
> > need to define "OpenStack Cloud" for brand management, we should be
> > thinking about it at the different levels of the stack. There could be a
> > separate set of "core" projects for IaaS and PaaS, for example.
>
> I agree that I'd like to see the project overall be inclusive instead of
> exclusive.
>
> >     Once "Core" is defined we can evaluate the need for a category that
> >     would still be in "OpenStack" but not have the "Core" label on it.
> >     Incubation could then lead two ways.
> >
> >
> > It seems like we want a "supported" category for projects the TC feels
> > are worth spending foundation resources on but the BoD does not want to
> > include in "core" and require that deployers use them to be able to
> > claim they are an "OpenStack Cloud" as you mention above. So projects
> > would start out in the community, move to "incubated" and then to
> > "supported" after the incubation period is up. They could apply
> > separately for "core" status, after being declared "supported" by the TC.
>
> This seems to be the crux of the issue.  If the OpenStack mark is going
> to be wrapped up in what "core" is, then I think it seems fine to keep
> it very limited, and perhaps to minimal IaaS components, but *only* if
> we have a place for everything else that is a positive addition to go.
> A new category like "supported" seems like a great idea to me.
>
> My gut feeling of where the line would be is that Heat, Ceilometer, and
> Horizon would all be in this new category, while everything else would
> remain the core.
>

That makes sense to me.

Doug


>
> --
> Russell Bryant
>
> _______________________________________________
> 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/20121107/ad50c20c/attachment.html>