<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 3 February 2016 at 04:28, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><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"><span class="">On 02/02/2016 10:03 PM, Matthew Treinish wrote:<br>
</span><div><div class="h5">> On Tue, Feb 02, 2016 at 05:09:47PM -0800, Armando M. wrote:<br>
>> Folks,<br>
>><br>
>> We have some IPv6 related bugs [1,2,3] that have been lingering for some<br>
>> time now. They have been hurting the gate (e.g. [4] the most recent<br>
>> offending failure) and since it looks like they have been without owners<br>
>> nor a plan of action for some time, I made the hard decision of skipping<br>
>> them [5] ahead of the busy times ahead.<br>
><br>
> So TBH I don't think the failure rate for these tests are really at a point<br>
> necessitating a skip:<br>
><br>
> <a href="http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_v6.TestGettingAddress.test_multi_prefix_slaac" rel="noreferrer" target="_blank">http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_v6.TestGettingAddress.test_multi_prefix_slaac</a><br>
> <a href="http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_dhcp6_stateless_from_os" rel="noreferrer" target="_blank">http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_dhcp6_stateless_from_os</a><br>
> <a href="http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_v6.TestGettingAddress.test_dhcp6_stateless_from_os" rel="noreferrer" target="_blank">http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_v6.TestGettingAddress.test_dhcp6_stateless_from_os</a><br>
><br>
> (also just a cool side-note, you can see the very obvious performance regression<br>
> caused by the keystonemiddleware release and when we excluded that version in<br>
> requirements)<br>
><br>
> Well, test_dualnet_dhcp6_stateless_from_os is kinda there with a ~10% failure<br>
> rate, but the other 2 really aren't. I normally would be -1 on the skip patch<br>
> because of that. We try to save the skips for cases where the bugs are really<br>
> severe and preventing productivity at a large scale.<br>
><br>
> But, in this case these ipv6 tests are kinda of out of place in tempest. Having<br>
> all the permutations of possible ip allocation configurations always seemed a<br>
> bit too heavy handed. These tests are also consistently in the top 10 slowest<br>
> for a run. We really should have trimmed down this set a while ago so we're only<br>
> have a single case in tempest. Neutron should own the other possible<br>
> configurations as an in-tree test.<br>
><br>
> Brian Haley has a patch up from Dec. that was trying to clean it up:<br>
><br>
> <a href="https://review.openstack.org/#/c/239868/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/239868/</a><br>
><br>
> We probably should revisit that soon, since quite clearly no one is looking at<br>
> these right now.<br>
<br>
</div></div>We definitely shouldn't be running all the IPv6 tests.<br>
<br>
But I also think the assumption that the failure rate is low is not a<br>
valid reason to keep a test. Unreliable tests that don't have anyone<br>
looking into them should be deleted. They are providing negative value.<br>
Because people just recheck past them even if their code made the race<br>
worse. So any legitimate issues they are exposing are being ignored.<br>
<br>
If the neutron PTL wants tests pulled, we should just do it.<br>
<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>Thanks for the support! Having said, I think it's important to make a judgement call on a case by case basis, because removing tests blindly might as well backfire.</div><div><br></div><div>In this specific instance and all things considered, merging [2] (or even better [1]) feel like a net gain.<br></div><div><br></div><div>Cheers,</div><div>Armando</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/239868/">https://review.openstack.org/#/c/239868/</a></div><div>[2] <a href="https://review.openstack.org/#/c/275457/">https://review.openstack.org/#/c/275457/</a></div><div> </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"><span class=""><font color="#888888">
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
</font></span><div class=""><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>