Jump to: navigation, search

Difference between revisions of "Zaqar/Incubation/Graduation"

(To Do)
(Updated status according to latest requirements draft)
Line 1: Line 1:
== Graduation ==
+
= Marconi Dashboard =
 
 
Deadline: '''Monday, February 10th'''
 
  
 
See also: https://etherpad.openstack.org/p/incubation-and-integration-requirements
 
See also: https://etherpad.openstack.org/p/incubation-and-integration-requirements
Line 7: Line 5:
 
Umbrella BP: https://blueprints.launchpad.net/marconi/+spec/graduation
 
Umbrella BP: https://blueprints.launchpad.net/marconi/+spec/graduation
  
==== To Do ====
+
== Incubation Requirements ==
 +
 
 +
===Scope===
 +
 
 +
{| class="wikitable"
 +
! scope="row" style="text-align:left" | Project must have a clear and defined scope.
 +
| Marconi's mission is "To produce an OpenStack messaging API and service that affords a variety of distributed application messaging patterns in an efficient, scalable and highly-available manner, and to create and maintain associated Python libraries and documentation." Marconi is a messaging and notifications service for the OpenStack product portfolio, supporting point-to-point, producer-consumer, publisher-subscriber models. Marconi is designed to perform and scale in a multi-tenant environment.
 +
|-
 +
! scope="row" style="text-align:left" | Project's scope should represent a measured progression for OpenStack as a whole.
 +
|Modern web applications are often built with SOA, and often require a messaging service to connect the various components of the application together. Also, several OS projects are looking for a way to surface notifications to users, and are looking to Marconi to provide a platform that can support this use case.
 +
|-
 +
! scope="row" style="text-align:left" | Project should not inadvertently duplicate functionality present in other OpenStack projects. If they do, they should have a clear plan and timeframe to prevent long-term scope duplication.
 +
|Marconi provides a multi-tenant messaging service to end-users (i.e., app developers) and so addresses a different use case from oslo messaging.
 +
|-
 +
! scope="row" style="text-align:left" | Project should leverage existing functionality in other OpenStack projects as much as possible
 +
|Marconi leverages Keystone for auth, and is easily deployed using OS IaaS. Marconi uses oslo utilities, as well as the oslo caching, logging, and configuration libraries. The project's tests use testrepository and hacking.
 +
|}
 +
 
 +
===Maturity===
 +
 
 +
{| class="wikitable"
 +
! scope="row" style="text-align:left" | Project should have an active team of contributors
 +
| We have had regular commits for the past two cycles from several individuals and organizations, including Red Hat, Rackspace, and IBM. See also: http://stackalytics.com/?release=icehouse&metric=commits&module=marconi
 +
|-
 +
! scope="row" style="text-align:left" | Project should not have a major architectural rewrite planned
 +
| For Juno we will be focusing on a minor API update (v1.1), operational maturity (improved monitoring, logging, security, performance), and adding notifications on top of what is already in place. A new transport layer design will be experimented with in order to better support non-HTTP drivers, but we do not anticipate it replacing the current transport layer during Juno.
 +
|-
 +
! scope="row" style="text-align:left" | Project APIs should be reasonably stable
 +
| The v1.0 API has been frozen for months, and is in production at Rackspace.
 +
|}
 +
 
 +
===Process===
 +
 
 +
{| class="wikitable"
 +
! scope="row" style="text-align:left" | Project must be hosted under stackforge (and therefore use git as its VCS)
 +
| N/A (Project has been moved to the openstack org since becoming incubated.)
 +
|-
 +
! scope="row" style="text-align:left" | Project should use oslo libraries or oslo-incubator where appropriate
 +
| Marconi uses oslo utilities, as well as the oslo caching, logging, and configuration libraries. The project's tests use testrepository and hacking.
 +
|-
 +
! scope="row" style="text-align:left" | If project is not part of an existing program, it needs to file for a new program concurrently with the Incubation request, and fill the corresponding requirements.
 +
| Done. We would, however, like to request the program name be changed from "Queues Service" to "Messaging Service" or similar.
 +
|-
 +
! scope="row" style="text-align:left" | Project must have a well-defined core review team, with reviews distributed amongst the team (and not being primarily done by one person)
 +
| We currently have 4 core team members representing 3 different companies. All members are active in reviews and code contributions.
 +
|-
 +
! scope="row" style="text-align:left" | Reviews should follow the same criteria as OpenStack projects (2 +2s before +A)
 +
| We have been following this process for quite some time now.
 +
|-
 +
! scope="row" style="text-align:left" | Project should use the official openstack lists for discussion
 +
| We use them for ML discussions, but often find IRC to be more effective for discussions in general (#openstack-marconi on freenode).
 +
|}
 +
 
 +
===QA===
 +
 
 +
{| class="wikitable"
 +
! scope="row" style="text-align:left" | Project must have a basic devstack-gate job set up
 +
| Done
 +
|}
 +
 
 +
===Documentation / User support===
 +
 
 +
{| class="wikitable"
 +
! scope="row" style="text-align:left" | Project must have docs for developers who want to contribute to the project
 +
| From day one, we've documented project description, requirements, use cases, and bps on the wiki: https://wiki.openstack.org/wiki/Marconi
 +
|-
 +
! scope="row" style="text-align:left" | Project must have a basic devstack-gate job set up
 +
| Done
 +
|-
 +
! scope="row" style="text-align:left" | Project should have API documentation for devs who want to add to the API, updated when the code is updated
 +
| We have docs on the wiki for [[https://wiki.openstack.org/wiki/Marconi/specs/api/v1|v1.0]] and [[https://wiki.openstack.org/wiki/Marconi/specs/api/v1.1|v1.1]]. The latter is kept up to date and discussed regularly as it evolves.
 +
|}
 +
 
 +
===Legal requirements===
 +
 
 +
{| class="wikitable"
 +
! scope="row" style="text-align:left" | Project must be licensed under the Apache License v2
 +
| Done
 +
|-
 +
! scope="row" style="text-align:left" | Project must have no library dependencies which effectively restrict how the project may be distributed or deployed
 +
| Marconi has a pretty tame list of dependencies. Note that pymongo and Falcon are Apache2, and that we have a SQLAlchemy driver so that operators can deploy a non-AGPL backend if they wish. See also: https://github.com/openstack/marconi/blob/master/requirements.txt
 +
|-
 +
! scope="row" style="text-align:left" | All contributors to the project must have signed the CLA
 +
| Done
 +
|-
 +
! scope="row" style="text-align:left" | Project must have no known trademark issues
 +
| Marconi has no known trademark issues. We've been using "Marconi" for over a year now, and nothing has come up.
 +
|}
 +
 
 +
 
 +
 
 +
== Graduation Requirements ==
 +
 
 +
===Scope===
 +
See answers to incubation scope, above.
 +
 
 +
===Maturity===
 +
 
 +
{| class="wikitable"
 +
! scope="row" style="text-align:left" | Project must have a large and diverse team of contributors
 +
| We have had regular commits for the past cycles from a diverse group of individuals and organizations, including Red Hat, Rackspace, and IBM. See also: http://stackalytics.com/?release=icehouse&metric=commits&module=marconi
 +
|-
 +
! scope="row" style="text-align:left" | Project must have completed integration work with other integrated projects, as communicated by the TC when accepted into incubation
 +
| We were asked to contribute a heat template (done), and dashboard integration was a nice to have (in progress, should be in J-1).
 +
|}
 +
 
 +
===Process===
 +
 
 +
{| class="wikitable"
 +
! scope="row" style="text-align:left" | Project must have a diverse core reviewers team (more than 4 people)
 +
| Marconi currently has 4 and we expect to add (at least) 1-2 more during Juno.
 +
|-
 +
! scope="row" style="text-align:left" | Core reviewers must enforce a minimum of 2 +2s before accepting a change
 +
| This has been enforced for quite some time now. We also strive to get several +1's, esp. for large changes.
 +
|-
 +
! scope="row" style="text-align:left" | Project should have engaged with marketing team to check suitable official name
 +
| TODO
 +
|-
 +
! scope="row" style="text-align:left" | Project must use OpenStack task, defect and design tracker(s)
 +
| Marconi has been using the standard tools for quite a while now.
 +
|}
 +
 
 +
===QA===
 +
 
 +
{| class="wikitable"
 +
! scope="row" style="text-align:left" | Project must have a devstack-gate job running. This gate job should install the project using devstack and then run tempest tests.  This job should run and vote in the check and gate pipelines for the project.  It is *not* required that this job is running for the projects it depends on.  This demonstrates that it would be easy to add the project to the integrated gate after graduation.
 +
| We have a devstack-gate job running. We are in the middle of fixing a bug that is causing the mysql backend to fail, and mongo is failing due to an outdated version being deployed in the gate. We should have one of [mysql, mongodb] working very soon, at which point we will make the tempest job voting.
 +
|-
 +
! scope="row" style="text-align:left" | Project must have decent unit test and functional tests coverage
 +
| Marconi has a large number of tests covering all operations that can be performed. Regression tests are added whenever a bug is discovered and fixed. Rackspace relies heavily on these tests to prove reliability of upstream code before pushing it to production.
 +
|-
 +
! scope="row" style="text-align:left" | Project must be compatible with all currently OpenStack-supported versions of Python
 +
| Marconi supports 2.6-2.7, and PyPy. Py3K support is close.
 +
|-
 +
! scope="row" style="text-align:left" | Project should have a decent record of triaging incoming bugs
 +
| We tend to triage bugs on a weekly basis (or even more frequently). Extra triaging happens around milestones closing and opening. In any case, it is done openly with discussions (typically) occuring via IRC. We are careful to not let critical bugs live very long before fixing them.
 +
|}
  
* [https://blueprints.launchpad.net/marconi/+spec/sql-storage-driver Ability to install marconi in a real production manner without having to install something AGPL]
+
===Documentation / User support===
* [https://blueprints.launchpad.net/python-marconiclient/+spec/python-marconiclient-v1 Client library]
 
* [https://blueprints.launchpad.net/marconi/+spec/heat-template Heat templates (nice to have)]
 
* [https://blueprints.launchpad.net/marconi/+spec/devstack-support Devstack integration] '''[DONE]'''
 
* [https://blueprints.launchpad.net/marconi/+spec/tempest-integration Tempest integration]
 
* [https://blueprints.launchpad.net/marconi/+spec/pecan-framework Investigate Pecan]
 
* [https://blueprints.launchpad.net/marconi/+spec/docs Documentation / User support]
 
* [https://blueprints.launchpad.net/marconi/+spec/marconi-horizon-integration Horizon integration (nice to have)]
 
* Focus on a single transport - avoid scope creep
 
  
==== Done ====
+
{| class="wikitable"
 +
! scope="row" style="text-align:left" | Project must have end-user docs such as API use, CLI use, Dashboard use
 +
| We have an end-user guide in the repo that documents getting started with Marconi and provides an API reference.
 +
|-
 +
! scope="row" style="text-align:left" | Project should have installation docs providing install/deployment in an integrated manner similar to other OpenStack projects, including configuration reference information for all options
 +
| There is a guide in the repo for developers and operators that documents installation, configuration of all options, HA, and accessing the API with the marconi client.
 +
|-
 +
! scope="row" style="text-align:left" | Project should have a proven history of providing user support (on the openstack@ mailing list and on Ask OpenStack)
 +
| We've had a fair number of questions on IRC, and we've supported Rackspace's deployment directly, but we haven't seen any requests on the openstack@ mailing list, presumably since the project is still relatively young. Regarding Ask, this wasn't previously on our radar, but we are tracking it now.
 +
|}
  
N/A
+
===Release management / Security===
 +
{| class="wikitable"
 +
! scope="row" style="text-align:left" | Project must have followed at least two common milestones (follow the common cycle at least since X-2)
 +
| We've been participating in the common release process starting with icehouse-2.
 +
|-
 +
! scope="row" style="text-align:left" | Project must have had at least one of their milestones handled by the release management team (at least the X-3 milestone)
 +
| See above.
 +
|-
 +
! scope="row" style="text-align:left" | Project must provide a 2+ person team that will handle the project specific vulnerability process
 +
| We will get some volunteers and take care of this at our next meeting.
 +
|}

Revision as of 18:45, 18 March 2014

Marconi Dashboard

See also: https://etherpad.openstack.org/p/incubation-and-integration-requirements

Umbrella BP: https://blueprints.launchpad.net/marconi/+spec/graduation

Incubation Requirements

Scope

Project must have a clear and defined scope. Marconi's mission is "To produce an OpenStack messaging API and service that affords a variety of distributed application messaging patterns in an efficient, scalable and highly-available manner, and to create and maintain associated Python libraries and documentation." Marconi is a messaging and notifications service for the OpenStack product portfolio, supporting point-to-point, producer-consumer, publisher-subscriber models. Marconi is designed to perform and scale in a multi-tenant environment.
Project's scope should represent a measured progression for OpenStack as a whole. Modern web applications are often built with SOA, and often require a messaging service to connect the various components of the application together. Also, several OS projects are looking for a way to surface notifications to users, and are looking to Marconi to provide a platform that can support this use case.
Project should not inadvertently duplicate functionality present in other OpenStack projects. If they do, they should have a clear plan and timeframe to prevent long-term scope duplication. Marconi provides a multi-tenant messaging service to end-users (i.e., app developers) and so addresses a different use case from oslo messaging.
Project should leverage existing functionality in other OpenStack projects as much as possible Marconi leverages Keystone for auth, and is easily deployed using OS IaaS. Marconi uses oslo utilities, as well as the oslo caching, logging, and configuration libraries. The project's tests use testrepository and hacking.

Maturity

Project should have an active team of contributors We have had regular commits for the past two cycles from several individuals and organizations, including Red Hat, Rackspace, and IBM. See also: http://stackalytics.com/?release=icehouse&metric=commits&module=marconi
Project should not have a major architectural rewrite planned For Juno we will be focusing on a minor API update (v1.1), operational maturity (improved monitoring, logging, security, performance), and adding notifications on top of what is already in place. A new transport layer design will be experimented with in order to better support non-HTTP drivers, but we do not anticipate it replacing the current transport layer during Juno.
Project APIs should be reasonably stable The v1.0 API has been frozen for months, and is in production at Rackspace.

Process

Project must be hosted under stackforge (and therefore use git as its VCS) N/A (Project has been moved to the openstack org since becoming incubated.)
Project should use oslo libraries or oslo-incubator where appropriate Marconi uses oslo utilities, as well as the oslo caching, logging, and configuration libraries. The project's tests use testrepository and hacking.
If project is not part of an existing program, it needs to file for a new program concurrently with the Incubation request, and fill the corresponding requirements. Done. We would, however, like to request the program name be changed from "Queues Service" to "Messaging Service" or similar.
Project must have a well-defined core review team, with reviews distributed amongst the team (and not being primarily done by one person) We currently have 4 core team members representing 3 different companies. All members are active in reviews and code contributions.
Reviews should follow the same criteria as OpenStack projects (2 +2s before +A) We have been following this process for quite some time now.
Project should use the official openstack lists for discussion We use them for ML discussions, but often find IRC to be more effective for discussions in general (#openstack-marconi on freenode).

QA

Project must have a basic devstack-gate job set up Done

Documentation / User support

Project must have docs for developers who want to contribute to the project From day one, we've documented project description, requirements, use cases, and bps on the wiki: https://wiki.openstack.org/wiki/Marconi
Project must have a basic devstack-gate job set up Done
Project should have API documentation for devs who want to add to the API, updated when the code is updated We have docs on the wiki for [[1]] and [[2]]. The latter is kept up to date and discussed regularly as it evolves.

Legal requirements

Project must be licensed under the Apache License v2 Done
Project must have no library dependencies which effectively restrict how the project may be distributed or deployed Marconi has a pretty tame list of dependencies. Note that pymongo and Falcon are Apache2, and that we have a SQLAlchemy driver so that operators can deploy a non-AGPL backend if they wish. See also: https://github.com/openstack/marconi/blob/master/requirements.txt
All contributors to the project must have signed the CLA Done
Project must have no known trademark issues Marconi has no known trademark issues. We've been using "Marconi" for over a year now, and nothing has come up.


Graduation Requirements

Scope

See answers to incubation scope, above.

Maturity

Project must have a large and diverse team of contributors We have had regular commits for the past cycles from a diverse group of individuals and organizations, including Red Hat, Rackspace, and IBM. See also: http://stackalytics.com/?release=icehouse&metric=commits&module=marconi
Project must have completed integration work with other integrated projects, as communicated by the TC when accepted into incubation We were asked to contribute a heat template (done), and dashboard integration was a nice to have (in progress, should be in J-1).

Process

Project must have a diverse core reviewers team (more than 4 people) Marconi currently has 4 and we expect to add (at least) 1-2 more during Juno.
Core reviewers must enforce a minimum of 2 +2s before accepting a change This has been enforced for quite some time now. We also strive to get several +1's, esp. for large changes.
Project should have engaged with marketing team to check suitable official name TODO
Project must use OpenStack task, defect and design tracker(s) Marconi has been using the standard tools for quite a while now.

QA

Project must have a devstack-gate job running. This gate job should install the project using devstack and then run tempest tests. This job should run and vote in the check and gate pipelines for the project. It is *not* required that this job is running for the projects it depends on. This demonstrates that it would be easy to add the project to the integrated gate after graduation. We have a devstack-gate job running. We are in the middle of fixing a bug that is causing the mysql backend to fail, and mongo is failing due to an outdated version being deployed in the gate. We should have one of [mysql, mongodb] working very soon, at which point we will make the tempest job voting.
Project must have decent unit test and functional tests coverage Marconi has a large number of tests covering all operations that can be performed. Regression tests are added whenever a bug is discovered and fixed. Rackspace relies heavily on these tests to prove reliability of upstream code before pushing it to production.
Project must be compatible with all currently OpenStack-supported versions of Python Marconi supports 2.6-2.7, and PyPy. Py3K support is close.
Project should have a decent record of triaging incoming bugs We tend to triage bugs on a weekly basis (or even more frequently). Extra triaging happens around milestones closing and opening. In any case, it is done openly with discussions (typically) occuring via IRC. We are careful to not let critical bugs live very long before fixing them.

Documentation / User support

Project must have end-user docs such as API use, CLI use, Dashboard use We have an end-user guide in the repo that documents getting started with Marconi and provides an API reference.
Project should have installation docs providing install/deployment in an integrated manner similar to other OpenStack projects, including configuration reference information for all options There is a guide in the repo for developers and operators that documents installation, configuration of all options, HA, and accessing the API with the marconi client.
Project should have a proven history of providing user support (on the openstack@ mailing list and on Ask OpenStack) We've had a fair number of questions on IRC, and we've supported Rackspace's deployment directly, but we haven't seen any requests on the openstack@ mailing list, presumably since the project is still relatively young. Regarding Ask, this wasn't previously on our radar, but we are tracking it now.

Release management / Security

Project must have followed at least two common milestones (follow the common cycle at least since X-2) We've been participating in the common release process starting with icehouse-2.
Project must have had at least one of their milestones handled by the release management team (at least the X-3 milestone) See above.
Project must provide a 2+ person team that will handle the project specific vulnerability process We will get some volunteers and take care of this at our next meeting.