N0. Does the project use the Neutron REST API or relies on proprietary backends?
networking-ovn implements a backend for the existing Neutron REST API. It is not a client of Neutron REST APIs. It also does not rely on any proprietary backends.
N1. Does the project integrate/use neutron-lib?
Yes. The project uses neutron-lib with an overall migration status of 11.66% as of October 10, 2016.
N2. Do project members actively contribute to help neutron-lib achieve its goal?
No. The project core team members are not actively contributing to neutron-lib.
N3. Do project members collaborate with the core team to enable subprojects to loosely integrate with the Neutron core platform by helping with the definition of modular interfaces?
The project team members have helped in this area by opening bug reports and providing fixes as appropriate (e.g. https://bugs.launchpad.net/neutron/+bug/1597898).
N4. How does the project provide networking services? Does it use modular interfaces as provided by the core platform?
The project uses the modular interfaces (ML2 and L3) provided by the core platform to enable networking services. Some of the project’s networking services are provided via native services instead of via neutron agents.
N5. If the project provides new API extensions, have API extensions been discussed and accepted by the Neutron drivers team? Please provide links to API specs, if required.
The project does not provide new API extensions.
D1. Does the project have a doc tox target, functional and continuously working? Provide proof (links to logs.openstack.org).
D2. If the project provide API extensions, does the project have an api-ref tox target, functional and continously working? Provide proof (links to logs.openstack.org).
D3. Does the project have a releasenotes tox target, functional and continously working? Provide proof.
D4. Describe the types of documentation available: developer, end user, administrator, deployer.
The project itself provides primarily developer, administrator and deployer documention at http://docs.openstack.org/developer/networking-ovn/, and relies on community OpenStack neutron documentation for end user documentation.
C1. Does the project have a Grafana dashboard showing historical trends of all the jobs available? Provide proof (links to grafana.openstack.org).
C2. Does the project have CI for unit coverage? Provide proof (links to logs.openstack.org)
C3. Does the project have CI for functional coverage? If so, does it include DB migration and sync validation?
Yes. The project does not introduce any Data Model at the moment and hence it does not require DB migration and sync validation.
C4. Does the project have CI for fullstack coverage?
C5. Does the project have CI for Tempest coverage? If so, specify nature (API and/or Scenario).
Yes. The jobs test both native and conventional networking services with both API and scenario tests as taken by the Tempest project.
C6. Does the project require CI for Grenade coverage?
A non-voting job is available. More is needed.
C7. Does the project provide multinode CI?
This area is under active development. Some pointers below.
C8. Does the project support Python 3.x? Provide proof.
Yes. Some pointers below.
R1. Does the project adopt semver?
R2. Does the project have release deliverables? Provide proof as available in the release repo.
Yes. The project has release deliverables with newton being the first.
R3. Does the project use upper-constraints?
Does the project integrate with OpenStack Proposal Bot for requirements updates?
S1. Does the project have stable branches and/or tags? Provide history of backports.
Yes. The project has stable branches with stable/newton being the first.
L1. If the project requires a client library, how does it implement CLI and API bindings?
The project does not require a client library.
|N0 | Y|
|N1 | Y|
|N2 | N|
|N3 | Y|
|N4 | Y|
|N5 | Y|
|D1 | Y|
|D2 | Y|
|D3 | Y|
|D4 | Y|
|C1 | Y|
|C2 | Y|
|C3 | Y|
|C4 | N|
|C5 | Y|
|C6 | N|
|C7 | N|
|C8 | Y|
|R1 | Y|
|R2 | Y|
|R3 | Y|
|R4 | Y|
|S1 | Y|
Final remarks: networking-ovn is a well managed project. It would be nice if members of the project would pay some of the neutron-lib tax for the wellbeing of the wider Neutron community but one can only wish for so much. The project lacks in area of upgrade and multinode testing, but the team is actively working to fill these gaps.