Networking-l2gw Scorecard

Neutron integration

• N0. Does the project use the Neutron REST API or relies on proprietary backends?

  Networking-l2gw implements its own set of Neutron API extensions on top of the Neutron core framework and it does so by using the service plugin model. The API exposed has open source implementations, and it provides a pluggable mechanism for proprietary backends.

• N1. Does the project integrate/use neutron-lib?

  Yes. The migration report shows that there are currently ~450 total imports. Neutron is imported ~100 times and Neutron-lib only ~10 times, for a migration percentage of 11.2000%. No periodic job against neutron-lib seems available.

• N2. Do project members actively contribute to help neutron-lib achieve its goal?

  None of the project core members have merged anything meaningful into neutron-lib (source: https://review.openstack.org/#/q/project:openstack/neutron-lib+status:merged,75).

• 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?

  Not particularly.

• N4. How does the project provide networking services? Does it use modular interfaces as provided by the core platform?

  Yes.

• 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.

  Not exactly. The project was one of the initial projects created during the early days of the Big Tent and Neutron decomposition. The API was accepted/approved by a smaller group of people who wanted to make progress on a topic that was largely stalled due to lack of community consensus.

Documentation

• D1. Does the project have a doc tox target, functional and continuously working? Provide proof (links to logs.openstack.org).

  Yes.

  • https://github.com/openstack/networking-l2gw/blob/master/tox.ini

• 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).

  There is no API reference published, though the API is detailed in its spec document.

  • https://raw.githubusercontent.com/openstack/networking-l2gw/master/specs/kilo/l2-gateway-api.rst

• D3. Does the project have a releasenotes tox target, functional and continously working? Provide proof.

  No.

• D4. Describe the types of documentation available: developer, end user, administrator, deployer.

  There is not a lot of documentation available.

  • http://docs.openstack.org/developer/networking-l2gw/

Continuous Integration

• C1. Does the project have a Grafana dashboard showing historical trends of all the jobs available? Provide proof (links to grafana.openstack.org).

  No.

• C2. Does the project have CI for unit coverage? Provide proof (links to logs.openstack.org)

  Yes.

  • http://status.openstack.org/openstack-health/#/g/project/openstack~2Fnetworking-l2gw

• C3. Does the project have CI for functional coverage? If so, does it include DB migration and sync validation?

  No. but DB migration and sync validation is provided by its unit job.

  • http://logs.openstack.org/99/380899/1/gate/gate-networking-l2gw-python35-db/f3af348/testr_results.html.gz

• C4. Does the project have CI for fullstack coverage?

  No.

• C5. Does the project have CI for Tempest coverage? If so, specify nature (API and/or Scenario).

  Latest Bot proposal shows only unit validation. Even though the project has API and scenario tests they are exercised with downstream CI because of lack of an pure software implementation of L2GW services.

  • https://review.openstack.org/#/c/357703/

• C6. How does a project validate upgrades on a continuous basis? Does the project require or support CI for Grenade coverage?

  Yes. But it has none.

• C7. Does the project provide multinode CI?

  No.

• C8. Does the project support Python 3.x? Provide proof.

  Yes.

  http://logs.openstack.org/03/357703/7/gate/gate-networking-l2gw-python35-db/b834ee7/testr_results.html.gz

Release footprint

• R1. Does the project adopt semver?

  Yes.

• R2. Does the project have release deliverables? Provide proof as available in the release repo.

  Yes, the release is responsibility of the neutron-release team.

• R3. Does the project use upper-constraints?

  Yes.

  • https://github.com/openstack/networking-l2gw/blob/master/tox.ini#L10

• Does the project integrate with OpenStack Proposal Bot for requirements updates?

  Yes.

  • https://github.com/openstack/requirements/commit/574736a84b9218e1d7ea860f82cb248975b7c1ca

Stable backports

• S1. Does the project have stable branches and/or tags? Provide history of backports.

  Yes, stable maintainance is responsibility of the neutron-stable team.

Client library

• L1. If the project requires a client library, how does it implement CLI and API bindings?

  There are Neutron CLI extensions but they have not been ported over to OSC.

  • https://github.com/openstack/networking-l2gw/tree/master/networking_l2gw/l2gatewayclient

Scorecard

Scorecard
N0 | Y
N1 | Y
N2 | N
N3 | N
N4 | Y
N5 | N
D1 | Y
D2 | N
D3 | N
D4 | N
C1 | N
C2 | Y
C3 | N
C4 | N
C5 | N
C6 | N
C7 | N
C8 | Y
R1 | Y
R2 | Y
R3 | Y
R4 | Y
S1 | Y
L1	N

Final remarks

Closing the gap on all the remaining unmet criteria in time for Ocata-1 (Nov 14 2016) seems challenging. Progress lacked during the Newton cycle. It is probably time for the core team to be rebooted.