Open Stack

On Tue, Mar 10, 2015 at 3:31 PM, James E. Blair <corvus at inaugust.com> wrote:

> Joe Gordon <joe.gordon0 at gmail.com> writes:
>
> > After watching the TC meeting, and double checking with the meeting notes
> > [0], it looks like the magnum vote was deferred to next week. But what
> > concerns me is the lack of action items assigned that will help make sure
> > next weeks discussion isn't just a repeat of what happened today.
>
> I believe we decided to talk about an application from a project _other_
> than Magnum during the next meeting to help us survey the existing
> applications and identify anything we would like to shore up before we
> proceed.  Then return to Magnum in a later meeting.
>
> I think that's important so that if we are going to check ourselves with
> the new process, that we do it without focusing unduly on Magnum's
> application, which I think is quite good.
>
> So I would like us to see where this thread gets us, whether there is
> more input to be digested from the ops summit, talk about other
> applications next week, and then get on to a vote on the Magnum
> application shortly.
>

Sounds like a good plan to me.

To get the ball rolling on the wider discussion I thought I would take a
quick look at the 4 applications we have today:

Disclaimer: I may be getting some of the details wrong here so take this
all with a large grain of salt.

1. python-openstackclient [0]
2. Magnum - OpenStack Containers Service [1]
3. Murano Application Catalog [2]
4.Group Based Policy (GBP) Project [3]

First lets consider these projects based on the old model [4] consisting of
Scope, Maturity, Process, API, QA, Documentation and Legal. of those items
lets look at scope, Maturity, QA.

*Scope*:
1. *Yes*. python-openstackclient has a clear scope and and place in
OpenStack in fact we already use it all over the place.
2. *Yes*. Magnum definitely doesn't overlap with any existing OpenStack
projects (especially nova). I think its safe to say it has a clear scope
and is a measured progression of openstack as a whole
3. *Maybe*. Not sure about the scope, it is fairly broad and there may be
some open ended corners, such as some references to billing. On the other
hand an application catalog sounds really useful and like a measured
progression for OpenStack as a whole. Murano may overlap with glance's
stated mission of  "To provide a service where users can upload and
discover data assets that are meant to be used with other services, like
images for Nova and templates for Heat." Murano also relies heavily on the
Mistral service which is still in stackforge itself.
4. *Maybe*. GBP has a clear scope, although a broad and challenging one
does not duplicate work and seems like a measured progression.

*Maturity*:
1. *Yes*, 6 or so very active reviewers from different companies. No
reworks planned
2. *Maybe*. Diverse set of contributors. Major architectural work may be
needed to remove single points of failure. Unclear On what the API actually
is today, some of it is a management API to provision kubranetes, some is a
pass through to kubranetes via the Magnum API (magnum runs 'kubectl create'
for you) and some requires using the user using the native kube API.
3. *Maybe* *Yes*. Active team, but not diverse. Not sure about rewrites.
Perhaps if there is overlap with other things.
4. *Maybe*. active team, Unclear on if a major rewrite is in its future

*QA*:
1. *Yes*
2. *No*. No devstack-gate job set up
3. *Yes*
4. *No*. No devstack-gate job running

When looking just these 3 requirements. Only python-openstackclient clearly
meets all of them, Magnum and GBP clearly fail the QA requirement. and
Murano is up in the air.

Now that we have some context of how these would have played out in the old
model, lets look at the new requirements [5].

*Aligns with the OpenStack Mission*:
Yes to all

*4 Opens:*
1. *Yes, *not sure if Dean was formally 'chosen' as PTL but that is easy to
sort out
2. *Yes*
3. *Yes, *similar detail about PTL
4. *Yes*, similar detail about PTL

*Supports Keystone*:
Yes for all

*Active team*:
Yes to all


[0] https://review.openstack.org/#/c/161885/
[1] https://review.openstack.org/#/c/161080/
[2] https://review.openstack.org/#/c/162745/
[3] https://review.openstack.org/#/c/161902/
[4]
http://governance.openstack.org/reference/incubation-integration-requirements.html
[5] http://governance.openstack.org/reference/new-projects-requirements.html


> -Jim
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20150310/08cb80dd/attachment.html>