On Feb 6, 2014, at 8:52 AM, Luke Gorrie <l...@snabb.co> wrote:

> 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.
> 
So, in general I don’t think this will fly because it’s my understanding the
OpenStack servers only test fully open source code. Allowing a third party
vendor system to run on the OpenStack servers as part of any functional
testing would open an entirely new can of worms here. I would suggest
asking this question on #openstack-infra as well for clarity since I don’t see
a response on the mailing list yet.

Thanks,
Kyle

> 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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to