On Tue, Mar 10, 2015 at 3:31 PM, James E. Blair <cor...@inaugust.com> wrote:
> Joe Gordon <joe.gord...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
