Move Provider Network APIs into core
The goal of this blueprint is to make the provider net API 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
I'm not opposed to moving the provider extension API to the core API for Grizzly. But I do not think the data models dealing with representing provider attributes and especially network bindings should be moved to the core DB models quite yet.
For one thing, the set of supported network_type values needs to be open-ended. We should not have to update the core just because a plugin implements a new network type. This means at least the validation of network_type and corresponding values for physical_network and segmentation_id need to be implemented in the plugin rather than the core.
For another, the Modular L2 plugin will (eventually) support multi-segment networks, where different segments of the same virtual network have different network_type, physical_network, and/or segmentation_id values. The ML2 plugin will be using a NetworkSegment table rather than the NetworkBinding table structures used currently in linuxbridge and openvswitch.
As described in the specification under https:/
-Bob
--- Update 2013/01/20
We are untargeting this from grizzly due to the dependency with https:/
This blueprint is probably more important. These APIs can be moved into core in the next release.
