Open Stack

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
> the
> >     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
> know
> >     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
> just
> >     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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/db48c7d3/attachment.html>