<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 15, 2014 at 11:55 AM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 08/15/2014 02:53 PM, Russell Bryant wrote:<br>
> On 08/15/2014 02:45 PM, Eric Windisch wrote:<br>
>> I have proposed a _silent_ check for Nova for integration of the Docker<br>
>> driver:<br>
>><br>
>>     <a href="https://review.openstack.org/#/c/114547/" target="_blank">https://review.openstack.org/#/c/114547/</a><br>
>><br>
>> It has been established that this code cannot move back into Nova until<br>
>> the tests are running and have a solid history of success. That cannot<br>
>> happen unless we're allowed to run the tests. Running a silent check on<br>
>> changes to Nova is the first step in establishing that history.<br>
>><br>
>> Joe Gordon suggests we need a spec to bring the driver back into Nova.<br>
>> Besides the fact that specs are closed and there is no intention of<br>
>> reintegrating the driver for Juno, I'm uncertain of proposing a spec<br>
>> without first having solid history of successful testing, especially<br>
>> given the historical context of this driver's relationship with Nova.<br>
>><br>
>> If we could enable silent checks, we could help minimize API skew and<br>
>> branch breakages, improving driver quality and reducing maintenance<br>
>> while we prepare for the Kilo spec + merge windows. Furthermore, by<br>
>> having a history of testing, we can seek faster inclusion into Kilo.<br>
>><br>
>> Finally, I acknowledge that we may be entering a window of significant<br>
>> load on the CI servers and I'm sensitive to the needs of the<br>
>> infrastructure team to remain both focused and to conserve precious<br>
>> compute resources. If this is an issue, then I'd like to plot a<br>
>> timeline, however rough, with the infrastructure team.<br>
><br>
> CI resources aside, I think enabling it sounds fine and useful.<br>
><br>
> Given resource concerns, maybe just adding it to the experimental<br>
> pipeline would be sufficient?  That doesn't run as often, but still<br>
> gives you the chance to run on demand against nova patches.  There are<br>
> other things in experimental for nova as well, so there will be other<br>
> people triggering runs.<br>
><br>
<br>
</div></div>And I missed that it's already in experimental.  Oops.<br>
<br>
Feature freeze is only a few weeks away (Sept 4).  How about we just<br>
leave it in experimental until after that big push?  That seems pretty<br>
reasonable.<br></blockquote><div><br></div><div>Sounds like a good idea to me too. Also I am unsure if we ant to have this running as silent for a long period of time. Yes, as experimental job its hard to get a large enough data set, so we need to generate a larger data set, but how big is big enough? Will running this job on silent for 1 week be enough? 2 weeks? </div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
--<br>
Russell Bryant<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>