Move l3 APIs into quantum core
The goal of this blueprint is to make l3 APIs, currently available as an extension, part of the quantum core API.
This work will also involve updates in the documentation (no separate blueprint will be needed)
Blueprint information
- Status:
- Complete
- Approver:
- dan wendlandt
- Priority:
- Medium
- Drafter:
- Salvatore Orlando
- Direction:
- Needs approval
- Assignee:
- Salvatore Orlando
- Definition:
- Superseded
- Series goal:
- None
- Implementation:
-
Deferred
- Milestone target:
- None
- Started by
- Completed by
- Salvatore Orlando
Related branches
Related bugs
Sprints
Whiteboard
Postponing to grizzly-3 in order to allow more time to work on other topixs.
---
Some comments regarding this blueprint and implications for "L3 router/floatingip" as a plugin (blueprint here) but it applies to service plugins in general and core API.
If the L3 API becomes a core API and L3 router/floatingip functionality is refactored so it *can* (not must) be provided as a service plugin then this will imply that the core API is no longer necessarily implemented by a single plugin. The network, subnet, and port resources will still be implemented by the (traditional) core plugins. The router and floatingip resources will be implemented by a L3 plugin, or, as today by the core plugin, depending on what core plugin implementers decide.
One way to achieve this is to modify the API router implementation in router.py in the following way:
The RESOURCES dict is extended so that each item includes a service type identifier that specifies which type plugin implements the resource. Something like:
RESOURCES = {'network': {'coll': 'networks', 'type': constants.CORE},
The APIRouter class (essentially the _map_resource method) is modified so that a plugin implementing the resource's service type is used when creating a controller for that resource.
QuantumManager's get_plugin method could be modified to take a (constants.CORE defaulted) service type argument and return the plugin that implements that service type.
Another required change (for core plugins to still be able to implement resources with type != 'CORE') is that core plugins have a function that reports which service types the core plugin implements. Something like
get_service_types() returning ['CORE', 'L3-ROUTER-NAT'] or whatever is supported.
I believe the above would allow the L3 router/floatingip resources (or any other resource) to be implemented by a separate L3 plugin or remain implemented by a core plugin.
Does this makes sense to you?
---
Update 2013-01-21
Untargeting from Grizzly. Priority should be given to high blueprints, and this one has some prereqs on other blueprints for l3 support in cisco and bigswitch plugins.
