<div dir="ltr"><div>Hi Steve,</div><div><br></div><div>Thanks for the continuing help!</div><div><br></div><div>On 29 July 2014 20:25, Steve Gordon <span dir="ltr"><<a href="mailto:sgordon@redhat.com" target="_blank">sgordon@redhat.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
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</div></blockquote><div><br></div><div>I am attempting to satisfy this. I've posted more information on the code review and also on the ml: <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-July/041662.html">http://lists.openstack.org/pipermail/openstack-dev/2014-July/041662.html</a></div>
<div><br></div><div>I hope this moves us a step towards satisfying the objections. I am optimistic because the use case is an important one and to me it seems like the design is in line with existing practice in Neutron.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">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.</div>
</blockquote><div><br></div><div>We are not adding a new hypervisor driver. but the VIF_VHOSTUSER feature does depend on a very recent QEMU (>= 2.1) and Libvirt (>= 1.2.7).</div><div><br></div><div>I would like to understand what (if any) CI implications this version requirement has on the Nova side.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""> 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:<br>
</div>
<div class=""><br>
> * Test with NFV-oriented features that are upstream in OpenStack.<br>
> * Test with NFV-oriented changes that are not yet upstream e.g. Neutron QoS<br>
API.<br>
<br>
</div>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.<br>
</blockquote><div><br></div><div>Sorry, I didn't explain myself very clearly.</div><div><br></div><div>On reflection, the question is quite generic, and I will reraise it under the [3rd-party][neutron] label.</div><div>
<br></div><div>There seems to be a chicken-and-egg situation where the CI is supposed to run tests with a new Neutron driver enabled, but that new Neutron itself driver is not merged and so it will not available with the Git refspec that Gerrit supplies to the CI.</div>
<div><br></div><div>Likely there is already a standard practice for this that we can find out about from the 3rd party gurus e.g. cherry-pick the driver into all tests.</div><div><br></div><div><br></div></div></div></div>