[openstack-dev] [all][qa][glance] some recent tempest problems

Sean Dague sean at dague.net
Thu Jun 15 21:22:31 UTC 2017

On 06/15/2017 01:04 PM, Brian Rosmaita wrote:
> 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
> project.
> 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.

It would be useful to provide detailed examples. Everything is trade
offs, and having the conversation in the abstract is very difficult to
understand those trade offs.


Sean Dague

More information about the OpenStack-dev mailing list