Nova should not require os-network extension to process requested_networks when running with quantum
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
Undecided
|
Phil Day |
Bug Description
Server create will only process "networks" if the os-networks extension is loaded.
When working with a quantum configuration and multiple networks you have to be able to pass in the requested network to avoid instances being attached to all networks, so this part of the request isn't really optional
However the os-network extension is not fully compatible with quantum, and the operations do map very well. For example:
- Network creation has a set of options that are pretty nova-net centric (such as VLAN)
- Network creation is limited to admins
- Network association and dis-association from projects is not the quanum model
- cidr from quantum is not shown correctly in the output of nova network-list and network-show
Rather than needing os-networks loaded and thereby exposing a bunch of calls that don't really map to quantum, it would be better to also allow processing of "networks" when the network api is configured to be quantum
Changed in nova: | |
assignee: | nobody → Phil Day (philip-day) |
Changed in nova: | |
status: | New → In Progress |
Changed in nova: | |
milestone: | none → grizzly-rc1 |
status: | Fix Committed → Fix Released |
Changed in nova: | |
milestone: | grizzly-rc1 → 2013.1 |
Reviewed: https:/ /review. openstack. org/23814 github. com/openstack/ nova/commit/ e0fd027d2d0cb09 39998204b200059 061771bc07
Committed: http://
Submitter: Jenkins
Branch: master
commit e0fd027d2d0cb09 39998204b200059 061771bc07
Author: Phil Day <email address hidden>
Date: Thu Mar 7 13:19:09 2013 +0000
Server create will only process "networks" if os-networks is loaded.
When working with a quantum configuration and multiple networks you
have to be able to pass in the requested network to avoid instances
being attached to all networks, so this part of the request isn't
really optional in practice
However the os-network extension is not fully compatible with
quantum, and the operations do map very well. For example:
- Network creation has a set of options that are pretty nova-nets
centric (such as VLAN)
- Network creation is limited to admins
- Network association and dis-association from projects is not
the quantum model
- cidr from quantum is not shown correctly in the output of nova
network-list and network-show
Rather than needing the os-networks extension to loaded and
thereby exposing a bunch of calls that don't really map to
quantum, it would be better to also allow processing of "networks"
when the network api is configured to be quantum
Fixes bug #1150250
Change-Id: I0cc1faf6417d7a 004dd9f0ff77286 0237fc94c57