[openstack-dev] [all][qa][glance] some recent tempest problems
doug at doughellmann.com
Thu Jun 15 20:12:06 UTC 2017
Excerpts from Brian Rosmaita's message of 2017-06-15 13:04:39 -0400:
> This isn't a glance-specific problem though we've encountered it quite
> a few times recently.
> Briefly, we're gating on Tempest jobs that tempest itself does not
> gate on. This leads to a situation where new tests can be merged in
> tempest, but wind up breaking our gate. We aren't claiming that the
> added tests are bad or don't provide value; the problem is that we
> have to drop everything and fix the gate. This interrupts our current
> work and forces us to prioritize bugs to fix based not on what makes
> the most sense for the project given current priorities and resources,
> but based on whatever we can do to get the gates un-blocked.
> As we said earlier, this situation seems to be impacting multiple projects.
> One solution for this is to change our gating so that we do not run
> any Tempest jobs against Glance repositories that are not also gated
> by Tempest. That would in theory open a regression path, which is why
> we haven't put up a patch yet. Another way this could be addressed is
> by the Tempest team changing the non-voting jobs causing this
> situation into voting jobs, which would prevent such changes from
> being merged in the first place. The key issue here is that we need
> to be able to prioritize bugs based on what's most important to each
> We want to be clear that we appreciate the work the Tempest team does.
> We abhor bugs and want to squash them too. The problem is just that
> we're stretched pretty thin with resources right now, and being forced
> to prioritize bug fixes that will get our gate un-blocked is
> interfering with our ability to work on issues that may have a higher
> impact on end users.
> The point of this email is to find out whether anyone has a better
> suggestion for how to handle this situation.
> Erno Kuvaja
> Glance Release Czar
> Brian Rosmaita
> Glance PTL
Asymmetric gating definitely has a way of introducing these problems.
Which jobs are involved?
More information about the OpenStack-dev