Jump to: navigation, search

Difference between revisions of "Zaqar/Incubation/Graduation"

(QA)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
= Marconi Dashboard =
+
= Zaqar Dashboard =
  
 
See also: https://etherpad.openstack.org/p/incubation-and-integration-requirements
 
See also: https://etherpad.openstack.org/p/incubation-and-integration-requirements
  
Umbrella BP: https://blueprints.launchpad.net/marconi/+spec/graduation
+
Umbrella BP: https://blueprints.launchpad.net/zaqar/+spec/graduation
  
Pecan evaluation (a graduation requirement specified by the TC at time of incubation): https://wiki.openstack.org/wiki/Marconi/pecan-evaluation
+
Pecan evaluation (a graduation requirement specified by the TC at time of incubation): https://wiki.openstack.org/wiki/Zaqar/pecan-evaluation
  
 
== Outstanding BPs ==
 
== Outstanding BPs ==
  
* https://blueprints.launchpad.net/marconi/+spec/tempest-integration -  
+
* https://blueprints.launchpad.net/zaqar/+spec/tempest-integration -  
 
** Waiting to fix mysql devstack issue in order to make the job voting
 
** Waiting to fix mysql devstack issue in order to make the job voting
 
** ETA for the fix is RC1 - see also https://bugs.launchpad.net/devstack/+bug/1294068
 
** ETA for the fix is RC1 - see also https://bugs.launchpad.net/devstack/+bug/1294068
Line 19: Line 19:
 
{| class="wikitable"
 
{| class="wikitable"
 
! scope="row" style="text-align:left" | Project must have a clear and defined scope.
 
! scope="row" style="text-align:left" | Project must have a clear and defined scope.
| Marconi provides a messaging platform for web and mobile application developers, supporting publish-subcribe, producer-consumer, point-to-point, and hyrbrid communication patterns. The project provides a simple, easy-to-use API designed according to direct feedback from users, and allows for a variety of options for backend storage, allowing operators to tailor the performance, durability, and scalability of their offerings to achieve a best-fit messaging solution for themselves and their users.
+
| Zaqar provides a messaging platform for web and mobile application developers, supporting publish-subcribe, producer-consumer, point-to-point, and hyrbrid communication patterns. The project provides a simple, easy-to-use API designed according to direct feedback from users, and allows for a variety of options for backend storage, allowing operators to tailor the performance, durability, and scalability of their offerings to achieve a best-fit messaging solution for themselves and their users.
 
|-
 
|-
 
! scope="row" style="text-align:left" | Project's scope should represent a measured progression for OpenStack as a whole.
 
! 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. Traditional message brokers were built for a different world; users today are looking for something that provides a first-class, multi-tenant HTTP API that affords a variety of modern messaging patterns for web and mobile apps. 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.
+
|Modern web applications are often built with SOA, and often require a messaging service to connect the various components of the application together. Traditional message brokers were built for a different world; users today are looking for something that provides a first-class, multi-tenant HTTP API that affords a variety of modern messaging patterns for web and mobile apps. Also, several OS projects are looking for a way to surface notifications to users, and are looking to Zaqar 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.
 
! 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.
+
|Zaqar 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
 
! 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.
+
|Zaqar leverages Keystone for auth, and is easily deployed using OS IaaS. Zaqar uses oslo utilities, as well as the oslo caching, logging, and configuration libraries. The project's tests use testrepository and hacking.
 
|}
 
|}
  
Line 35: Line 35:
 
{| class="wikitable"
 
{| class="wikitable"
 
! scope="row" style="text-align:left" | Project should have an active team of contributors
 
! 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
+
| 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=zaqar
 
|-
 
|-
 
! scope="row" style="text-align:left" | Project should not have a major architectural rewrite planned
 
! scope="row" style="text-align:left" | Project should not have a major architectural rewrite planned
Line 51: Line 51:
 
|-
 
|-
 
! scope="row" style="text-align:left" | Project should use oslo libraries or oslo-incubator where appropriate
 
! 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.
+
| Zaqar 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.
 
! 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.
Line 63: Line 63:
 
|-
 
|-
 
! scope="row" style="text-align:left" | Project should use the official openstack lists for discussion
 
! 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).
+
| We use them for ML discussions, but often find IRC to be more effective for discussions in general (#openstack-zaqar on freenode).
 
|}
 
|}
  
Line 77: Line 77:
 
{| class="wikitable"
 
{| class="wikitable"
 
! scope="row" style="text-align:left" | Project must have docs for developers who want to contribute to the project
 
! 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
+
| From day one, we've documented project description, requirements, use cases, and bps on the wiki: https://wiki.openstack.org/wiki/Zaqar
 
|-
 
|-
 
! scope="row" style="text-align:left" | Project must have a basic devstack-gate job set up
 
! scope="row" style="text-align:left" | Project must have a basic devstack-gate job set up
Line 83: Line 83:
 
|-
 
|-
 
! 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
 
! 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.
+
| We have docs on the wiki for [[https://wiki.openstack.org/wiki/Zaqar/specs/api/v1|v1.0]] and [[https://wiki.openstack.org/wiki/Zaqar/specs/api/v1.1|v1.1]]. The latter is kept up to date and discussed regularly as it evolves.
 
|}
 
|}
  
Line 93: Line 93:
 
|-
 
|-
 
! scope="row" style="text-align:left" | Project must have no library dependencies which effectively restrict how the project may be distributed or deployed
 
! 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 are building drivers for 2 more production-ready backends besides MongoDB, in case operators aren't comfortable using an AGPL database. See also: https://github.com/openstack/marconi/blob/master/requirements.txt
+
| Zaqar has a pretty tame list of dependencies. Note that pymongo and Falcon are Apache2, and that we are building drivers for 2 more production-ready backends besides MongoDB, in case operators aren't comfortable using an AGPL database. See also: https://github.com/openstack/zaqar/blob/master/requirements.txt
 
|-
 
|-
 
! scope="row" style="text-align:left" | All contributors to the project must have signed the CLA
 
! scope="row" style="text-align:left" | All contributors to the project must have signed the CLA
Line 99: Line 99:
 
|-
 
|-
 
! scope="row" style="text-align:left" | Project must have no known trademark issues
 
! 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.
+
| Zaqar has no known trademark issues. We've been using "Zaqar" for over a year now, and nothing has come up.
 
|}
 
|}
  
Line 127: Line 127:
 
|-
 
|-
 
! scope="row" style="text-align:left" | Project should have engaged with marketing team to check suitable official name
 
! scope="row" style="text-align:left" | Project should have engaged with marketing team to check suitable official name
| Marconi has been renamed to Zaqar because there were trademark issues.
+
| Zaqar has been renamed to Zaqar because there were trademark issues.
 
|-
 
|-
 
! scope="row" style="text-align:left" | Project must use OpenStack task, defect and design tracker(s)
 
! scope="row" style="text-align:left" | Project must use OpenStack task, defect and design tracker(s)
Line 153: Line 153:
 
{| class="wikitable"
 
{| class="wikitable"
 
! scope="row" style="text-align:left" | Project must have end-user docs such as API use, CLI use, Dashboard use
 
! 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.
+
| We have an user-guide up-to-date with what's in the repo. More patches will be landing in the next few days.
 
|-
 
|-
 
! 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
 
! 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.
+
| 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 zaqarclient.
 
|-
 
|-
 
! 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)
 
! 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.
+
| 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. We've folks looking at Ask OpenStack and other medias.
 
|}
 
|}
  

Latest revision as of 12:02, 2 September 2014

Zaqar Dashboard

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

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

Pecan evaluation (a graduation requirement specified by the TC at time of incubation): https://wiki.openstack.org/wiki/Zaqar/pecan-evaluation

Outstanding BPs

Incubation Requirements

Scope

Project must have a clear and defined scope. Zaqar provides a messaging platform for web and mobile application developers, supporting publish-subcribe, producer-consumer, point-to-point, and hyrbrid communication patterns. The project provides a simple, easy-to-use API designed according to direct feedback from users, and allows for a variety of options for backend storage, allowing operators to tailor the performance, durability, and scalability of their offerings to achieve a best-fit messaging solution for themselves and their users.
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. Traditional message brokers were built for a different world; users today are looking for something that provides a first-class, multi-tenant HTTP API that affords a variety of modern messaging patterns for web and mobile apps. Also, several OS projects are looking for a way to surface notifications to users, and are looking to Zaqar 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. Zaqar 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 Zaqar leverages Keystone for auth, and is easily deployed using OS IaaS. Zaqar 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=zaqar
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 Zaqar 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-zaqar 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/Zaqar
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 Zaqar has a pretty tame list of dependencies. Note that pymongo and Falcon are Apache2, and that we are building drivers for 2 more production-ready backends besides MongoDB, in case operators aren't comfortable using an AGPL database. See also: https://github.com/openstack/zaqar/blob/master/requirements.txt
All contributors to the project must have signed the CLA Done
Project must have no known trademark issues Zaqar has no known trademark issues. We've been using "Zaqar" 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, Catalyst and IBM. See also: http://stackalytics.com/?release=juno&metric=commits&module=zaqar
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 horizon integration was a nice to have (99% done, will be in J-1). There are several other areas where Zaqar could integrated with other projects. We've worked on a list of use-cases with folks from those teams.

Process

Project must have a diverse core reviewers team (more than 4 people) Zaqar currently has 6 core members representing multiple organizations.
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 Zaqar has been renamed to Zaqar because there were trademark issues.
Project must use OpenStack task, defect and design tracker(s) Zaqar 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. Done
Project must have decent unit test and functional tests coverage Zaqar has a large number of tests covering all operations that can be performed. Regression tests are added whenever a bug is discovered and fixed.
Project must be compatible with all currently OpenStack-supported versions of Python Zaqar supports 2.6, 2.7, 3.3, and PyPy
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) occurring 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 user-guide up-to-date with what's in the repo. More patches will be landing in the next few days.
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 zaqarclient.
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. We've folks looking at Ask OpenStack and other medias.

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 Done. Team members are listed on our wiki.