ODL V2 Driver 101: V1 Driver Explained

As I’ve recently been working intensively on the OepnStack Neutron’s ODL V2 driver, I feel it’s a good idea to share my insights and knowledge about it to the benefit of the world.

This is a multi-post series as it’s easier to write & read than a single blob of blog..

ODL Driver V1

So before even explaining about V2 it makes sense to understand what’s the V1 Driver, what are it’s problems.

If you’re wondering what a Driver even means, you should check out https://wiki.openstack.org/wiki/Neutron/ML2#Mechanism_Drivers.


V1 was the naive implementation of the mechanism driver concept to integrate ODL into Neutron. The driver basically plugs into the POSTCOMMIT hooks for the various resources, and forwards it to an internal implementation which in turn has the following super simple logic:

  • Are we out of sync?
    • Yes: Do a full-sync, i.e. try so POST all the resource collections in Neutron over to ODL.
    • No: Try to mirror the operation to ODL (i.e. POST/PUT/DELETE for Create/Update/Delete) and if it fails mark that we’re out of sync.

This obviously has some very serious problems (which were also identified by the ODL & Neutron communities):

  • ODL is not really synchronous, so the REST call succeeds it doesn’t mean the action really happened on ODL.
  • The “synchronous” call can be a bottleneck.
  • Intermittent failure would cause a full-sync of the entire Neutron DB.
    • Bad at scale.
    • Bad idea even without scale, since you just POST mindlessly even if the resource already exists.
  • Doesn’t handle a “cold reboot” of ODL where ODL is missing the data from the DB (could happen with older ODL versions, and possibly in newer ones if you wipe the serialized cache).
  • Doesn’t really handle race conditions:
    • For example, create subnet and then create port could be sent in parallel by the driver in an HA Neutron environment, causing the port creation to fail.
    • Full-sync could possible recreate deleted resources if the deletion happens in parallel.

Although the naive solution is pretty KISS, it’s not good for any real world use case other than for POCs. Hence, the networking-odl community set out to design and implement a better solution to integrate ODL with Neutron.

In the next post we’ll explore the proposed design, and dive into the details and the reason why stuff was done the way it was done.

Post TOC


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s