----- Original Message -----
> From: "Luke Gorrie" <l...@snabb.co>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Cc: "Nikolay Nikolaev" <n.nikol...@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 <sgor...@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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
