<p dir="ltr"><br>
On Jun 12, 2014 9:03 AM, "Matt Riedemann" <<a href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>> wrote:<br>
><br>
><br>
><br>
> On 6/12/2014 10:51 AM, Matthew Treinish wrote:<br>
>><br>
>> On Fri, Jun 13, 2014 at 12:41:19AM +0930, Christopher Yeoh wrote:<br>
>>><br>
>>> On Fri, Jun 13, 2014 at 12:25 AM, Dan Smith <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>> wrote:<br>
>>><br>
>>>> I think it'd be OK to move them to the experimental queue and a periodic<br>
>>>>><br>
>>>>> nightly job until the v2.1 stuff shakes out.  The v3 API is marked<br>
>>>>> experimental right now so it seems fitting that it'd be running tests in<br>
>>>>> the experimental queue until at least the spec is approved and<br>
>>>>> microversioning starts happening in the code base.<br>
>>>>><br>
>>>><br>
>>>> I think this is reasonable. Continuing to run the full set of tests on<br>
>>>> every patch for something we never expect to see the light of day (in its<br>
>>>> current form) seems wasteful to me. Plus, we're going to (presumably) be<br>
>>>> ramping up tests on v2.1, which means to me that we'll need to clear out<br>
>>>> some capacity to make room for that.<br>
>>>><br>
>>>><br>
>>> Thats true, though I was suggesting as v2.1microversions rolls out  we drop<br>
>>> the test out of v3 and move it to v2.1microversions testing, so there's no<br>
>>> change in capacity required.<br>
>><br>
>><br>
>> That's why I wasn't proposing that we rip the tests out of the tree. I'm just<br>
>> trying to weigh the benefit of leaving them enabled on every run against<br>
>> the increased load they cause in an arguably overworked gate.<br>
>><br>
>>><br>
>>> Matt - how much of the time overhead is scenario tests? That's something<br>
>>> that would have a lot less impact if moved to and experimental queue.<br>
>>> Although the v3 api as a whole won't be officially exposed, the api tests<br>
>>> test specific features fairly indepdently which are slated for<br>
>>> v2.1microversions on a case by case basis and I don't want to see those<br>
>>> regress. I guess my concern is how often the experimental queue results get<br>
>>> really looked at and how hard/quick it is to revert when lots of stuff<br>
>>> merges in a short period of time)<br>
>><br>
>><br>
>> The scenario tests tend to be the slower tests in tempest. I have to disagree<br>
>> that removing them would have lower impact. The scenario tests provide the best<br>
>> functional verification, which is part of the reason we always have failures in<br>
>> the gate on them. While it would make the gate faster the decrease in what were<br>
>> testing isn't worth it. Also, for reference I pulled the test run times that<br>
>> were greater than 10sec out of a recent gate run:<br>
>> <a href="http://paste.openstack.org/show/83827/">http://paste.openstack.org/show/83827/</a><br>
>><br>
>> The experimental jobs aren't automatically run, they have to be manually<br>
>> triggered by leaving a 'check experimental' comment. So for changes that we want<br>
>> to test the v3 api on a comment would have to left. To prevent regression is why<br>
>> we'd also have the nightly job, which I think is a better compromise for the v3<br>
>> tests while we wait to migrate them to the v2.1 microversion tests.<br>
>><br>
>> Another, option is that we make the v3 job run only on the check queue and not<br>
>> on the gate. But the benefits of that are slightly more limited, because we'd<br>
>> still be holding up the check queue.<br>
>><br>
>> -Matt Treinish<br>
>><br>
>><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">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
> Yeah the scenario tests need to stay, that's how we've exposed the two big ssh bugs in the last couple of weeks which are obvious issues at scale.<br>
><br>
> I still think experimental/periodic is the way to go, not a hybrid of check-on/gate-off.  If we want to explicitly test v3 API changes we can do that with 'recheck experimental'.  Granted someone has to remember to run those, much like checking/rechecking 3rd party CI results.</p>

<p dir="ltr">++</p>
<p dir="ltr">><br>
> One issue I've had with the nightly periodic job is finding out where the results are in an easy to consume format.  Is there something out there for that?  I'm thinking specifically of things we've turned off in the gate before like multi-backend volume tests and allow_tenant_isolation=False.<br>

><br>
> -- <br>
><br>
> Thanks,<br>
><br>
> Matt Riedemann<br>
><br>
><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">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</p>