Difference between revisions of "Neutron/Spec-l3apis-into-core"
| Line 5: | Line 5: | ||
The goal of this blueprint is to make L3 API part of the official 'core' Quantum API, as agreed durin the Grizzly summit. | The goal of this blueprint is to make L3 API part of the official 'core' Quantum API, as agreed durin the Grizzly summit. | ||
| − | From the user perspective, | + | |
| + | From the user perspective, there will be little to no changes (see 'API' section). | ||
| + | Plugin implementors should be aware of the changes in the DB model discussed in the 'Data Model Changes' section. | ||
| + | Also, new plugins introduced into the Quantum repository are now required to implement the L3 base plugin. | ||
== Use Cases == | == Use Cases == | ||
| + | |||
| + | This blueprint does not introduce any new use case. | ||
== Implementation Overview == | == Implementation Overview == | ||
| Line 17: | Line 22: | ||
== API == | == API == | ||
| − | + | The 'router:external' attribute (an extended attribute of the network resource) should be renamed simply to 'external' as the 'router' extension alias won't exist anymore. | |
| + | As this will generate an incompatible change for Folsom users, use of 'router:external' attribute as an alias for 'router:external' will still be allowed. | ||
| + | |||
| + | Use of 'router:external' in place of 'external' should be deprecated in the Grizzly API reference. | ||
== Test Cases == | == Test Cases == | ||
| Line 23: | Line 31: | ||
As this blueprint is not going to significantly change functionalities offered by the Quantum service, we do not anticipate new test cases or test modules. | As this blueprint is not going to significantly change functionalities offered by the Quantum service, we do not anticipate new test cases or test modules. | ||
However, for routines and methods which should be added during the implementation, appropriate unit tests will be provided. | However, for routines and methods which should be added during the implementation, appropriate unit tests will be provided. | ||
| + | |||
| + | == Open Questions == | ||
| + | |||
| + | Should this change bump the API version to 2.1, or shall we keep using 2.0. | ||
| + | Bumping to 2.1 will allow us to keep using 'router:external' when requests are sent to /v2.0/networks and just 'external' when requests are sent to /v2.1 | ||
| + | On the other hand it will add the burden of maintaining both 2.0 and 2.1 releases of the Quantum API. As we currently we do not have a plan for phasing out old, backward compatible releases, and adding new ones, this might constitute a problem in the long run. | ||
| + | Community feedback is solicited in order to reach a consensus here. Should the community should be unable to reach a consensus, API version should stay to 2.0 | ||
Revision as of 17:14, 13 January 2013
Move L3 APIs into Quantum core
Scope
The goal of this blueprint is to make L3 API part of the official 'core' Quantum API, as agreed durin the Grizzly summit.
From the user perspective, there will be little to no changes (see 'API' section). Plugin implementors should be aware of the changes in the DB model discussed in the 'Data Model Changes' section. Also, new plugins introduced into the Quantum repository are now required to implement the L3 base plugin.
Use Cases
This blueprint does not introduce any new use case.
Implementation Overview
Data Model Changes
Configuration variables
API
The 'router:external' attribute (an extended attribute of the network resource) should be renamed simply to 'external' as the 'router' extension alias won't exist anymore. As this will generate an incompatible change for Folsom users, use of 'router:external' attribute as an alias for 'router:external' will still be allowed.
Use of 'router:external' in place of 'external' should be deprecated in the Grizzly API reference.
Test Cases
As this blueprint is not going to significantly change functionalities offered by the Quantum service, we do not anticipate new test cases or test modules. However, for routines and methods which should be added during the implementation, appropriate unit tests will be provided.
Open Questions
Should this change bump the API version to 2.1, or shall we keep using 2.0. Bumping to 2.1 will allow us to keep using 'router:external' when requests are sent to /v2.0/networks and just 'external' when requests are sent to /v2.1 On the other hand it will add the burden of maintaining both 2.0 and 2.1 releases of the Quantum API. As we currently we do not have a plan for phasing out old, backward compatible releases, and adding new ones, this might constitute a problem in the long run. Community feedback is solicited in order to reach a consensus here. Should the community should be unable to reach a consensus, API version should stay to 2.0
