Ocata - Stadium health

For details about criteria please check Stadium documents.

Meeting the minimum bar

Neutron integration

The most basic criteria for neutron integration is the adoption of neutron-lib, with periodic checking. Going forward, the project team must demonstrate steps towards 100% migration over neutron-lib imports. No red flags in architectural and design decisions when building networking components must be present. API definition and reference documentation will need to be made available in the neutron-lib repo.

Acceptance test

Check that the Grafana dashboard displays correctly the periodic job, and that artifacts in the periodic output shows at least one successful run.

• http://logs.openstack.org/periodic/

• http://grafana.openstack.org/

Assessment

• networking-bagpipe: OK.

• networking-odl: OK.

• networking-bgpvpn: OK.

• networking-midonet: OK.

• neutron-dynamic-routing: OK.

• neutron-fwaas: OK.

• networking-ovn: OK.

• networking-sfc: OK.

Documentation

Documentation (developer, deployer and end-user as required), release notes and API reference (where applicable).

Acceptance test

Check for a working link to the documentation. Check for a working link to release notes for the latest release (Newton). Check for a working link to API reference.

• http://docs.openstack.org/developer/openstack-projects.html

• https://releases.openstack.org/newton/index.html

• http://developer.openstack.org/api-ref/networking/

Assessment

• networking-bagpipe: OK.

• networking-odl: OK.

• networking-bgpvpn: needs API documentation.

• networking-midonet: needs API documentation.

• neutron-dynamic-routing: needs API documentation.

• neutron-fwaas: OK.

• networking-ovn: OK.

• networking-sfc: needs API documentation.

Continuous Integration

Grafana dashboard must be available; unit (both py2x and py3x) and tempest (API and scenario) jobs must be gating and stable. This means that regex expressions to skip basic networking tests will not be tolerated. For projects that have DB migrations, sync tests must be available.

Acceptance test

Check for Grafana dashboard presence. Check for passing unit tests. Check for gating tempest tests. Check for scenario tests. Check for DB migration tests.

• http://grafana.openstack.org/

• http://status.openstack.org/openstack-health/

Assessment

• networking-bagpipe: OK.

• networking-odl: OK.

• networking-bgpvpn: OK.

• networking-midonet: OK.

• neutron-dynamic-routing: needs scenario tests. Needs DB/sync validation.

• neutron-fwaas: OK.

• networking-ovn: OK.

• networking-sfc: OK.

Release footprint

Semver, upper-constraints, and bot proposal integrated are a must. Release tarballs and release notes must be available on releases.openstack.org. There should be at least one published deliverable for each of the supported releases.

Acceptance test

Look for tarball and release note link available on releases.openstack.org. Check for the version. Check for presence of project on requirement repo. Check for use of upper-constraints.

• https://releases.openstack.org/newton/index.html

• https://releases.openstack.org/independent.html

• https://github.com/openstack/requirements/blob/master/projects.txt

• http://codesearch.openstack.org/?q=UPPER_CONSTRAINTS_FILE&i=nope&files=&repos=

Assessment

• networking-bagpipe: OK.

• networking-odl: OK.

• networking-bgpvpn: OK.

• networking-midonet: OK.

• neutron-dynamic-routing: OK.

• neutron-fwaas: OK.

• networking-ovn: OK.

• networking-sfc: OK.

Stable backports

Stable branches aligned with neutron branches are a must.

Acceptance test

Check for supported stable branches (mitaka and newton). Check that tox_install.sh pins to the right branch.

• http://git.openstack.org/cgit/openstack/<project-name>/?h=stable%2Fnewton

• http://codesearch.openstack.org/?q=tox_install.sh&i=nope&files=&repos=

Assessment

• networking-bagpipe: OK.

• networking-odl: OK.

• networking-bgpvpn: OK.

• networking-midonet: OK.

• neutron-dynamic-routing: OK.

• neutron-fwaas: OK.

• networking-ovn: OK.

• networking-sfc: OK.

Client library

For projects that need client extensions OSC bindings must be present.

Acceptance test

Check for presence of OSC bindings in python-neutronclient.

• https://github.com/openstack/python-neutronclient/tree/master/neutronclient/osc/v2

• https://github.com/openstack/python-neutronclient/blob/master/setup.cfg

Assessment

• networking-bagpipe: N/A.

• networking-odl: N/A.

• networking-bgpvpn: needs porting to python-neutronclient.

• networking-midonet: needs porting to python-neutronclient.

• neutron-dynamic-routing: needs porting to python-neutronclient.

• neutron-fwaas: OK.

• networking-ovn: N/A.

• networking-sfc: needs porting to python-neutronclient.

Summary

Project	Integration	Docs	CI	Release	Maintenance	CLI
networking-bagpipe	Met	Met	Met	Met	Met	N/A
networking-odl	Met	Met	Met	Met	Met	N/A
networking-bgpvpn	Met	Needs work	Met	Met	Met	Needs work
networking-midonet	Met	Needs work	Met	Met	Met	Needs work
neutron-dynamic-routing	Met	Needs work	Needs work	Met	Met	Needs work
neutron-fwaas	Met	Met	Met	Met	Met	Met
networking-ovn	Met	Met	Met	Met	Met	N/A
networking-sfc	Met	Needs work	Met	Met	Met	Needs work
neutron-vpnaas (*)	Met	Needs work	Needs work	Met	Needs work	Needs work
networking-l2gw (*)	Needs work	Needs work	Needs work	Needs work	Needs work	Needs work
networking-calico (*)	Needs work	Needs work	Needs work	Needs work	Needs work	N/A
networking-onos (*)	Needs work	Needs work	Needs work	Needs work	Needs work	N/A

(*) To re-apply for inclusion in Pike or future releases.

Scorecards

• Networking-bagpipe Scorecard
• Networking-bgpvpn Scorecard
• Networking-calico Scorecard
• Networking-l2gw Scorecard
• Networking-midonet Scorecard
• Networking-odl Scorecard
• Networking-onos Scorecard
• Networking-ovn Scorecard
• Networking-sfc Scorecard
• Neutron-dynamic-routing Scorecard
• Neutron-fwaas Scorecard
• Neutron-vpnaas Scorecard

How Reconcile API and client bindings

One key step of the stadium evolution effort is to consolidate API definitions/documentation and client bindings into neutron-lib and python-neutronclient respectively. If all of the criteria are met and the outstanding ones are Docs and CLI, then it is clear that in order to complete the effort end-to-end and keep the project in the neutron governance, a project team is left to contribute the API definition, its API reference documentation and the client bindings to neutron-lib and python-neutronclient respectively.

In order to address this need, please follow these steps:

• Propose a patch to neutron-lib that includes API definition and API documentation. Use topic ‘stadium-implosion’. You can break down API definition and API reference into separate patches, but this will lengthen the merge process. Please use the same topic for both patches, in case you break this down.

• Propose a patch to python-neutronclient that includes OSC commands, CLI documentation as well as API bindings. Use topic ‘stadium-implosion’ as hinted above. Make the client patch depend on the neutron-lib patch and not vice versa. That is because, should the API patch crash and burn for whatever reason, we do not need to revert the client patch prior to a client release.

Once all of the outstanding ‘stadium-implosion’ patches have merged a new release of neutron-lib and python-neutronclient is going to be cut. At this point, when the Bot Proposal change merges, the API definitions can be used in the subproject, and that seals the completion of the stadium effort for Ocata.

NOTE: Merging of these patches are pending confirmation that all the outstanding work has been addressed, but review will proceed nonetheless.