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
