feat: Dynamic network segments for each VLAN Group

[stevekeay]

This was opened to address PUC-787

The old scheme used a Nautobot plugin to assign a VLAN number outside of
Openstack, and this is what was configured on the switch. This caused
issues because Neutron had no knowledge of these VLANs, which make it
difficult to have Neutron drive any layer 3 services or even trunk ports.

Now we have Neutron allocate "Dynamic" network segments instead, and
these are pushed to Nautobot, to keep Nautobot's VLANs in sync with
Neutron's Network Segments.

To facilitate we are using the "physical network" of each Ironic
baremetal port to identify the vlan group where that switch port lives.
For every vlan group we have created a Network Segment Range with the
same name. Dynamic network segments of type "VLAN" are assigned from
those ranges.

We implement some new API calls to replace the "prep switch interface"
and "detach port" Nautobot jobs which were previously making interface
updates in addition to assigning VLAN numbers. Specifically, we now
update the vlans on the switch port and we toggle it's "provisioning"
state.

Undersync is invoked with a VLAN Group parameter. We now identify the
VLAN Group by name instead of UUID. The name is directly discoverable
from Neutron whereas the UUID would have to be looked up in Nautobot.
(Undersync was already updated to accept either type of parameter.)

In Neutron we now exclusively use type "VXLAN" and so all support for
type "VLAN" Networks has been removed. This also includes the
"provisioning" network which has been recreated as type VXLAN in our
environment.

There is an opportunity to remove our special "vlan 4010" case handling
of the provisioning network and have this created by Neutron using the
same mechanisms as for as any other tenant network, but that has not
happened yet.

Trunk ports have first-class support in Neutron but they are handled by
a separate model, disjoint from "normal" ports, and using trunk ports
exercises totally different ml2 driver callbacks. Trunk port support
is coming in a separate future PR.

[cardoe]

Reading through now, we won't need this code because we just need to create the correct network segment ranges for the "network" vlan groups which will match up with Nautobot.

[stevekeay]

It seems like we would need to find the baremetal port, perhaps by MAC address, and then look up its physical_network. This complicates things, so leaving it as a task to clean up later once we get this all working.

[cardoe]

Will you include a detailed description in the PR?

[Copilot]

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (1)

python/neutron-understack/neutron_understack/tests/test_trunk.py:1

• [nitpick] The removal of the entire trunk tests may lead to a gap in test coverage for trunk-related functionality. Please ensure that either this functionality is no longer needed or that its behavior is covered by alternative tests.

Entire file removed