[openstack-dev] Current biggest OpenStack gate fail culprit - neutron bug #1194026
john.griffith at solidfire.com
Thu Jul 11 15:53:00 UTC 2013
On Thu, Jul 11, 2013 at 9:38 AM, Russell Bryant <rbryant at redhat.com> wrote:
> On 07/11/2013 11:28 AM, John Griffith wrote:
> > On Thu, Jul 11, 2013 at 9:16 AM, Dan Smith <dms at danplanet.com
> > <mailto:dms at danplanet.com>> wrote:
> > > In the corner to my left, our current largest gate reset culprit
> > > appears to be neutron bug #1194026 - weighing in with 62 rechecks
> > > since June 24th (http://status.openstack.org/rechecks/)
> > So, with some of the highest rates of patch traffic we've seen over
> > last couple of weeks before the H2 deadline, I think this is really
> > becoming a problem. I think merge times are through the roof as a
> > result.
> > Since the neutron gate is not a full tempest run, I think we should
> > consider making a temporary change. I know that turning it into a
> > non-voting job is not a popular solution, and I hate to even suggest
> > it. However, it's just a subset of the tests anyway and I think the
> > Well to be blunt, if there's not even anybody assigned to the defect and
> > it's significantly impacting
> > the progress of every other project. I don't know that it's such a bad
> > idea. The process worked, it
> > identified an issue, now it's known/understood however it's causing
> > significant turmoil everywhere else.
> > Are we gaining anything by having it continue to fail and do rechecks
> > for the next week?
> +1 to making it non-voting until this is resolved. This is a sensitive
> week for gate and check times.
> > impact is currently overshadowing the potential for regression
> > detection, given the relatively small amount of coverage. Is this
> > something people would consider?
> > Of course, the other option is to try to skip the offending test if
> > we're running with neutron support, which may help. Since we don't
> > what the problem is and it *seems* to be an issue with resources not
> > becoming available before a timeout (AIUI), I worry that this will
> > move the problem elsewhere.
> Disabling a specific test would be preferred IMO, but if that's not
> sufficient, I'd +1 downgrading the whole thing to non-voting for now.
Excellent point, test_008_check_public_network_connectivity. If it's
possible to log the results but not fail the gate for this I think that
would be ideal, otherwise skip that test for now.
> Russell Bryant
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev