4.5 KiB
CreateVM supports subnet specified
https://blueprints.launchpad.net/nova/+spec/selecting-subnet-when-creating-vm
Currently the network info specified as part of server creation is limited to network-id, port-id, and ip address. When a network has multiple subnets then we need to also be able to specify a subnet-id.
Problem description
Currently the network info specified as part of server creation is limited to network-id, port-id, and ip address.
So if an network has multiple subnets in it, it's impossible to select which of the possible subnets a VM should be created in. You only could choose an ip address in one subnet and then create an instance. But this is not a convenient way. Moreover, this method is also not available for bulk instances creation.
Proposed change
- Add one optional param 'subnet-id' in networking structure of 'spawn'.
- This parameter will affect in 'allocate_for_instance()' in nova/network/neutronv2/api.py.
- Bulk instances creation with 'subnet-id' will be supported, as the 'net-uuid' is specified.
Alternatives
None
Data model impact
None
REST API impact
- The new 'spawn' rest API in v2::
-
/v2/{project_id}/servers
- {
-
'server':{ ... 'networks': [ { 'subnet-id': '892b9731-044a-4c87-b003-1e75869028c0' } ... ] ... }
}
- and in v3 it is like::
-
/v3/servers
- {
-
'server':{ ... 'networks': [ { 'subnet-id': '892b9731-044a-4c87-b003-1e75869028c0' } ... ] ... }
}
- Here, the <string> 'subnet-id' means the subnet your instances want to be created in. No default value.
- If 'subnet-id' is not a string or uuid-like, a BadRequest exception will be raised.(HTTP 400)
- The status code will be HTTP 202 when the request succeeded as usual, and the response body won't be changed.
In the current implement in Nova, the network info specified is limited to network-id, port-id, and ip address, and port-id has the highest priority. So, we also need to point the priority during server creation.
The 'port' parameter still has the highest priority here.
That means, if both 'port' & 'subnet-id' are specified, 'port' will be used and the 'subnet-id' won't effect here.
The 'subnet-id' has the same priority with 'v4-fixed-ip'/'v6-fixed-ip'.
That means, if both 'subnet-id' & 'v4-fixed-ip'/'v6-fixed-ip' are specified, compatibility validation of these two arguments will be executed.
- If it passed, the ip address you assigned will be used as usual.
- If not, a BadRequest exception will be raised.(HTTP 400)
The 'net-uuid' parameter still has the lowest priority like before.
That means, if both 'subnet-id' & 'net-id' are specified, 'subnet-id' will effect here and 'net-uuid' will be ignored like port specified.
Security impact
None
Notifications impact
None
Other end user impact
The related works in python-novaclient will also be added. After this modification, user could create instances with 'subnet-id' specified like 'net-uuid' does via CLI.
Performance Impact
None
Other deployer impact
None
Developer impact
None
Implementation
Assignee(s)
Assignee: wingwj <wingwj@gmail.com>
Work Items
In nova:
- Add 'subnet-id' to 'create' in API layer
- Use 'subnet-id' for 'allocate_for_instance()' in nova/network/neutronv2/api.py
- Add related tests both API & nova-compute
In python-novaclient:
- Add 'subnet-id' support in python-novaclient
- Add related tests in python-novaclient
In tempest:
- Related test-cases will definitely be added here
In doc:
- The API modification will also be registered in openstack-doc
Dependencies
None
Testing
The unit tests need to be added in each related projects like I described in <Work Items> part. After the modifications, all changed methods above will be verified together.
Documentation Impact
The 'server creation' in API & CLI documentations will need to be updated to:
- Reflect the new 'subnet-id' parameter and explain its usage
- Explain the priority of network info during server creation
References
None