[RFE] Get me a network
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
Wishlist
|
Henry Gessau |
Bug Description
As part of the "get me a network" work outlined in https:/
The current Neutron v2 api calls that Nova makes to neutron live in nova/network/
# (1) Retrieve non-public network list owned by the tenant.
nets = neutron.
# (2) Retrieve public network list.
nets += neutron.
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_
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_
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!
Changed in neutron: | |
assignee: | nobody → Brian Haley (brian-haley) |
tags: |
added: rfe-approved removed: get-me-a-network rfe |
Changed in neutron: | |
importance: | High → Wishlist |
Changed in neutron: | |
milestone: | none → mitaka-1 |
Changed in neutron: | |
milestone: | mitaka-1 → mitaka-2 |
Changed in neutron: | |
milestone: | mitaka-2 → mitaka-3 |
summary: |
- Change Neutron so that it can auto-allocate networks + [RFE] Change Neutron so that it can auto-allocate networks |
summary: |
- [RFE] Change Neutron so that it can auto-allocate networks + [RFE] Get me a network |
Changed in neutron: | |
status: | Triaged → In Progress |
Changed in neutron: | |
assignee: | Brian Haley (brian-haley) → Henry Gessau (gessau) |
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.