As part of the "get me a network" work outlined in https://review.openstack.org/#/c/196803/ we need to be able to auto-allocate Neutron networks for tenants. This is an RFE for those changes.
The current Neutron v2 api calls that Nova makes to neutron live in nova/network/neutronv2/api.py - specifically in _get_available_networks(). In the 'nova boot' case where no network has been specified, it makes two calls to neutron:
# (1) Retrieve non-public network list owned by the tenant.
search_opts = {'tenant_id': project_id, 'shared': False}
nets = neutron.list_networks(**search_opts).get('networks', [])
# (2) Retrieve public network list.
search_opts = {'shared': True}
nets += neutron.list_networks(**search_opts).get('networks', [])
The first will get any existing networks with this tenant_id, the second any shared networks the admin as pre-configured. If nothing exists the boot will error out and fail.
I'm proposing a new API, tentatively called "retrieve_networks", that while similar to "list_networks", can also be given additional information such as a flag parameter, that can signal neutron to auto-allocate a network and return it to the caller. This will be created as an extension, such that a caller could determine if it is supported before calling it (or falling-back to the old method).
The arguments to it can either be similar to "list_networks", or something like { ids: [], tenant_id: None, flags: [] }, where flags can be one or more values such as:
SHARED - return any shared networks
ALLOCATE - if no network exists, auto-allocate one based on config settings
This new API call would only need to be used from the call to _get_available_networks() in allocate_for_instance(), and not from the others.
This could either be a single-step process, where a single POST is done, or a two-step process, such that a GET is used first. We need to ask the API working group what the current recommendation would be. An alternative approach would be to put this logic in a library that Nova can call, rather than baking it into Nova.
The neutron configuration will be done in a new database table, such that updating config files and restarting services are not required. Initially, this will be just a few variables:
- network name to use (private_network)
- subnet name to use (private_subnet)
- subnet cidr to use (10.0.0.0/24)
- router name to use (private_router)
- external network to attach router to (must be a UUID ?)
This information - names and CIDR range for the initial subnet, can be the same for every tenant since they are private networks and over-lapping IPs are allowed in this case. The recommendation would be to use an address range in the RFC 1918 space unless otherwise specified.
A future enhancement could be to use subnet_pools for this.
In order to eliminate duplicate default networks being created, the database layer MUST use some sort of distributed locking (based on tenant_id) such that simultaneous calls to different neutron API servers for this new resource do not both succeed. The preferred outcome is for the second (and subsequent) calls to block, and return the network allocated by the first.
So it's in one place, the details that still need some ironing are:
1) Get recommendation from API working group
2) DB schema
3) DB locking
4) Buy-in from Nova, as this affects the nova-neutron API
5) Type of beer desired for first landed patch :) It's Friday here people!
Please feel free to comment!
This seems like a reasonable thing to me, thanks for writing it up Brian! The subnetpools integration at a future date would be pretty cool, but it seems it's an enhancement and could be deferred to later as you indicate here.