feat: Remove Nautobot integration from ml2 mechanism driver #1234
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
stevekeay
force-pushed
the
remove-nautobot-integration
branch
from
5e11bad to
130d044
Compare
stevekeay
changed the title
stevekeay
force-pushed
the
remove-nautobot-integration
branch
20 times, most recently
from
537900f to
ca1cf03
Compare
stevekeay
force-pushed
the
remove-nautobot-integration
branch
6 times, most recently
from
0aff356 to
0b63beb
Compare
stevekeay
force-pushed
the
remove-nautobot-integration
branch
5 times, most recently
from
ef6250c to
fd032c5
Compare
The driver was performing synchronous updates to keep Nautobot up-to-date with changes to networks, prefixes, etc. This approach has a number of drawbacks. We are no longer treating Nautobot as the authoritative source for IP space, network names, etc. Whenever a user is prevented from doing something because Nautobot said "no", it is always seen as a problem or bug in our system. The expected behaviour is that all valid openstack operations should succeed. Here we remove all Nautobot integration from the driver, with the intention of updating Nautobot asynchronously using a new mechanism.
This does part of what the ml2 driver was doing to update networks and subnets in Nautobot.
stevekeay
force-pushed
the
remove-nautobot-integration
branch
from
fd032c5 to
6581d77
Compare
cardoe
approved these changes
Sep 23, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The driver was performing synchronous updates to keep Nautobot up-to-date with changes to networks, prefixes, etc. This approach has a number of drawbacks.
We are no longer treating Nautobot as the authoritative source for IP space, network names, etc. Whenever a user is prevented from doing something because Nautobot said "no", it is always seen as a problem or bug in our system. The expected behaviour is that all valid openstack operations should succeed.
Here we remove all Nautobot integration from the driver, and we move that functionality to event handlers (via argo workflows) that update Nautobot asynchronously in response to the events that openstack publishes on rabbitmq. If this serverless style becomes a drain on resources, we can easily implement a service that will make a persistent connection to rabbitmq and process messages as they arrive - avoiding the cost of spinning up a python container for every message would vastly increase the throughput, and be arguably simpler than the whole argo events setup.
Thus far we only update UCVNIs, Namespaces and Prefixes. Prefixes are currently put into a Namespace belonging to the Network. The original intention was to have a "global" namespace in Nautobot into which we would put all prefixes that are visible on the Rackspace public network. This is probably still a laudable goal (to be able to answer questions like "who is using this IP address") but it was broken by recent changes to how we represent those things in Openstack. Networks used to have a flag that clearly demarcated public versus private, but now I think we need to query routers and suchlike to get an accurate picture. I have left this for a future PR. (Note that this is already broken in the current codebase, I just disabled it here completely to avoid confusion).
Also note that we don't yet know exactly what data people NEED in Nautobot -- some of the data we put there originally was to allow Nautobot to be a source of truth for Undersync, but that turned out to be a bad idea. The event-handling code is not straightforward and it's going to take some work to maintain all the nautbot vlans, interface vlan memberships, VNI numbers, etc. I was not planning on implementing any of that stuff until we have a concrete use case for that data being present in Nautobot.