Open Stack

----- Original Message -----
> From: "Luke Gorrie" <luke at snabb.co>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Cc: "Nikolay Nikolaev" <n.nikolaev at virtualopensystems.com>
> Sent: Tuesday, July 29, 2014 12:28:55 PM
> Subject: Re: [openstack-dev] [NFV][CI][third-party] The plan to bring up Snabb NFV CI for Juno-3
> 
> Hi Steve,
> 
> On 29 July 2014 17:21, Steve Gordon <sgordon at redhat.com> wrote:
> 
> > I've added the [third-party] tag as well to ensure this catches the
> > broadest segment of relevant people.
> >
> 
> Thanks!
> 
> 
> > are any modifications to upstream Open vSwitch required to support Snabb?
> >
> 
> Good question. No, this uses a separate vswitch called Snabb Switch. Snabb
> Switch is a small user-space program that you assign some network
> interfaces to. It runs independent of any other networking you are doing on
> other ports (OVS, DPDK-OVS, SR-IOV, etc).

OK, that's what I thought - thanks for confirming.

> Have you already attempted to solicit some core reviewers in Nova and
> > Neutron
> 
> How does one normally do that? We are getting help but I am not exactly
> sure how people have found us beyond chat in #openstack-nfv :-).
> 
> Two Neutron core reviewers are making the requirements there very clear to
> us, both on the code and the CI.

Ideally this is fairly organic, the NFV group certainly serves as a forum for coordinating what work is out there in this space but ultimately it is necessary to also liaise with and meet the expectations of the actual projects (e.g. Neutron and Nova in this case). This is an area where we as a group still have a lot of work to do, in my opinion.

I see that there is some discussion to this end in the code submission for the new mechanism driver:

    https://review.openstack.org/#/c/95711/

It appears to me the expectation/desire from Mark and Maru here is to see a lot more justification of the use cases for this driver and the direction of the current implementation so while it is positive that it got the attention of some core reviewers early there are some hard questions that will need to be answered to continue making progress with this for Juno.

> One Nova core reviewer is helping us too. I would like to better understand
> CI requirements on the Nova side (e.g. does the Neutron tempest testing
> regime provide adequate coverage for Nova or do we need to do more?). This
> is our first contribution to Nova so there is a risk that we overlook
> something important.

Typically third party CI is only provided/required for Nova when adding/maintaining a new hypervisor driver - at least that seems to be the case so far. I know in your earlier email you mentioned also wanting to use this third party CI to also test a number of other scenarios, particularly:

> * Test with NFV-oriented features that are upstream in OpenStack.
> * Test with NFV-oriented changes that are not yet upstream e.g. Neutron QoS
API.

I am not sure how this would work - perhaps I misunderstand what you are proposing? As it stands the third-party CI jobs ideally run on each change *submitted* to gerrit so features that are not yet *merged* still receive this CI testing today both from the CI managed by infra and the existing third-party CI jobs? Or are you simply highlighting that you wish to test same with snabbswitch? Just not quite understanding why these were called out as separate cases.

Thanks,

Steve