[RFE] On-demand segment and subnet allocation
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Won't Fix
|
Wishlist
|
Unassigned |
Bug Description
While routed networks [1] provides us the capability of managing L2 segments and related subnets with a view of L3 network, it assumes that the related infrastructure resources are always provisioned (vlans, host-segment bindings, subnets) beforehand and is not managed by neutron. However, in a large deployment cloud, there are use cases for on-demand resource provisioning.
- On-demand segment provisioning:
A host can be multi-tenancy, so when a host is provisioned, it may be unknown which tenant's VMs will be scheduled to the host, so some segments may not be needed for the host. On the other hand, new tenant can be added later on. So, it will be good if we can dynamically create the segment (i.e. create the vlan on the ToR) when the first VM of the tenant is scheduled under the ToR, then we don't need to pre-allocate all the possible vlans and create segments for all the ToRs.
The information that is known during host onboarding is the ToR that the host is located. We can model this as a BridgeGroup object (a group of vlans/l2 segments spanning across the same set of hosts, which are usually connected to a group of network devices, and the number of devices is usually 1, e.g. the ToR connecting the hosts under a rack), and BridgeGroup-Host mapping. And when the first neutron port is requested to be created on a routed network for a host under a BridgeGroup, a new segment is created within the BridgeGroup and bound to the host.
(Not sure if BridgeGroup is a good name here, maybe we can call it Physnet)
- On-demand subnet provisioning:
In a shared infrastructure the workload location is flexible, so it is hard to predict the number of IPs required for a segment. To use IP resource (especially IPv4) efficiently, it will be good to be able to dynamically allocate subnets to a segment only when it is needed, i.e. when there are workloads scheduled to the segment.
This feature request requires [1] but put additional requirements on top of it.
Changed in neutron: | |
importance: | Undecided → Wishlist |
description: | updated |
The BridgeGroup object proposed here maps to the physical_network attribute of NetworkSegment, but will be a first class citizen in the model.