[openstack-dev] [neutron][ml2] Maintaining support for the Tail-f NCS mech driver in Icehouse

Luke Gorrie luke at snabb.co
Thu Feb 6 14:52:43 UTC 2014


Howdy!

My name is Luke and I'm helping my friends at Tail-f Systems to
support Neutron with their NCS [1] product. This went really smoothly
for us on the Havana cycle, but lately we're having a harder time with
Icehouse. In particular, our attempt to fulfill the 3rd party testing
requirements has caused a lot of frustration for the #openstack-infra
team around New Year. So I'm writing now to look for a good solution.

Our goal for Icehouse is to keep our mechanism driver officially
supported. The code already works, and has unit tests to keep it
working. The risk we want to avoid is going on the dreaded
"deprecated" list for some other reason, which would confuse our
customers.

For background, our mechanism driver is about 150 lines of code. It
translates each network/port/subnet API call into a REST/JSON
notification to an external system. That external system returns HTTP
"200 OK". That's about all. It's a pretty trivial program.

In December I sat down with Tobbe Tornqvist and we tried to setup
Jenkins 3rd party testing. We created a Vagrantfile that spins up an
Ubuntu VM, installs Neutron and NCS, and performs integration tests
with them connected together. We hooked this into Jenkins with a
service account.

This went fine to start with, but after Christmas our tests started
failing due to random setup issues with 'tox', and the script started
making -1 votes. Those -1's created major headaches for the
infrastructure team and others upstream, I am sorry to say, and ended
up requiring a messy process of manual cleanup, and a public flogging
for us on IRC. Bad feeling all around ...

And that's where we are today.

Now, reviewing the situation, I would love to find a solution that
doesn't make us deprecated _and_ doesn't require us to be so deeply
hooked into the OpenStack Jenkins infrastructure.

Could we, for example, write an accurate emulator for the external
system so that the MD code can be tested on OpenStack's own servers?
That would suit us very well. It seems like a reasonable request to
make given the simplicity of our driver code.

Hoping for a simple solution...

Cheers,
-Luke & friends at Tail-f

[1] http://blog.ipspace.net/2013/05/tail-f-network-control-system-first.html



More information about the OpenStack-dev mailing list