[RFE] Allow subnets from different subnet pools on the same network when using address scopes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
In Progress
|
Wishlist
|
Ryan Tidwell |
Bug Description
Currently, neutron enforces that on any given network, all subnets of the same address family (IPv4/6) must be all allocated from the same subnet pool. This restriction was put in place before the concept of address scopes existed, and was meant to help enforce the uniqueness of subnet CIDR's associated with a network.
When address scopes are used, we really only need to enforce that all subnets on a given network belong to the same address scope for each address family. This unlocks use cases for operators that allow them to build different subnet pools to be used with specific subnet service types and allocate them from different pools.
For example:
Suppose an operator has different blocks of addresses for floating IP's and FIP agent gateway ports. This change would allow the operator to manage the FIP range from one subnet pool and FIP gateway addresses from another pool, which is something they can't do today because neutron only allows subnets to be placed on the network if they are allocated from the same pool.
Proposed Changes:
- When address scopes are not used neutron behaves as it currently does, enforcing all subnets of the same address family on the same network be allocated from the same subnet pool
- When address scopes are used the "same subnet pool" constraint is relaxed, and the check made is that all subnets belong to the same address scope
- Logic will be added to subnet pool updates to block movement between address scopes when moving the pool would cause one or more subnets allocated from the pool to violate the "same address scope" constraint.
- Logic will be added to the subnet "off-board" case to block the operation when "off-boarding" the requested subnet(s) causes a violation of the "same address scope" constraint.
As an alternative implementation, introducing address_scope_v4 and address_scope_v6 fields to the network resource would also give us a way of associating networks with the address scope. Since these constraints need to be enforced on the network, perhaps networks need to be aware of address scopes.
Changed in neutron: | |
importance: | Undecided → Wishlist |
tags: | added: rfe |
Changed in neutron: | |
status: | New → Confirmed |
tags: |
added: rfe-approved removed: rfe-triaged |
This makes sense. Let's bring it to the drivers