[RFE] Allow subnets from different subnet pools on the same network when using address scopes

[Ryan Tidwell]

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.

[Miguel Lavalle (minsel)]

This makes sense. Let's bring it to the drivers

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/667511

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/667644

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/667644
Committed: https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=d4415186690493c728e461d9bea9b32bfe246321
Submitter: Zuul
Branch: master

commit d4415186690493c728e461d9bea9b32bfe246321
Author: Ryan Tidwell <email address hidden>
Date: Wed Jun 26 10:04:00 2019 -0500

    Introduce NetworkAddressScopeAffinityError

    This introduces NetworkAddressScopeAffinityError, which is to be
    raised when address scope affinity constraints on a network are
    violated.

    Change-Id: Id541059b8fe0ab74035819516f079d93bb76d43c
    Partial-Bug: 1830240
    Implements: subnets-different-pools-same-net