This document describes a plan to replace the current home-grown WSGI framework, including REST controllers, with a solution entirely based on the Pecan framework 
The specification discussed in this document can make use of the V3 plugin specification, though it is no longer assumed to be dependent on that specification. See  for more details.
This specification addresses a number of issues arising from the fact that Neutron so far has been relying on and evolving its own framework for managing web service lifecycle and dispatch API operations to plugins.
In a nutshell: replace the existing framework with Pecan, remove the current code, and ensure that operators are unaffected by the change.
This means that we expect the following for the Kilo release:
No data model change expected.
Even if this patch has a deep impact on the Neutron management layer, the REST API itself will not change at all, and will preserve its capabilities in terms of resources, available operations, filtering, pagination and sorting.
Radical changes in the framework handling REST API requests always have a potential security impact.
In this case, since we are moving away from a home grown framework to one which is already widely adopted across OpenStack projects, the overall security level should increase.
The REST API layer is currently responsible for sending notifications such as those needed by the Telemetry service. With these change the notifications will not be handled in the REST API layer anymore, but moved within the plugin interface as specified in 
End users will not even notice the difference between a server running the home grown framework and one which switched to Pecan.
No significant impact expected. We have however no measurement available to justify this claim.
For this reason performance measurements should be done as part of this blueprint implementation to ensure that switching to Pecan does not negatively impact application performance.
For the purpose of this work, Rally will be used to provide before/after benchmarks. If other tools such as OsProfiler are deemed useful, they will be used as well in the evaluation.
IPv6-related APIs and IPAM capabilities will be unchanged.
We expect the deployer impact to be minimal. The main difference introduced by this change, from a deployer perspective is the fact that the HTTP server will be split from the AMQP server.
For green-field deployments this will not be a problem at all. It will also provide deployers with the desirable option of deploying the HTTP and AMQP servers on different nodes.
For existing deployments, updates should be smooth and transparent. The only difference would be that after an upgrade there would not be a single neutron server service, but two - one for the REST API, and one for RPC over AMQP.
New extensions will need to be developed in a different way. This will be thoroughly documented in developer documentation.
Moving away from the home-grown framework will allow the community to focus exclusively on Neutron’s business logic. Moreover, members of the Neutron community will also be encouraged to contribute back to Pecan.
A mailing list discussion  on REST API frameworks has been used to provide some guidance. For WSME, even if it is an interesting solution to increase code maintanability, and ease the development process, we struggled during some early experiments to make it work with the current extension model. Even if it might be argued that the problem in this case is the extension model, we are unable to recommend it as a part of this blueprint.
While not a direct dependency, the V3 plugin interface  is listed in the case it is proposed again for Liberty.
Once the changes are in place and integrated with the new plugin interface discussed in , gate tests should run as usual. We do not expect this change to have any impact that might trigger race conditions leading to intermittent gate failures.
On the other hand, this change will have a significant impact on unit testing. Most unit tests exercise the REST API server and with this change these unit tests will be inevitably broken. Under this proposal we therefore expect significant changes in the “base classes” for unit test, such as .
Besides, new modules introduced as a part of this blueprint should be thoroughly unit tested, with a target level of coverage between 90% and 100%. Test coverage should be verified with tox -ecover.
No new tests are anticipated.
Even if API functional testing will eventually be a relevant part of Neutron’s functional testing suite, this is outside the scope of this spec.
Please see previous section.
As the specification discussed in this document changes the way in which the Neutron server is deployed because of the split between the HTTP and RPC over AMQP server, this will need to be appropriately documented in the admin guide.
|||Pecan documentation: http://pecan.readthedocs.org|
|||(1, 2, 3, 4, 5, 6, 7) v3 plugin interface: https://review.openstack.org/#/c/140527/|
|||Pecan hooks: http://pecan.readthedocs.org/en/latest/hooks.html|
|||Falcon WSGI framework: http://falconframework.org/|