<div class="zcontentRow"> <p><a href="https://review.openstack.org/#/c/471352/" _src="https://review.openstack.org/#/c/471352/">https://review.openstack.org/#/c/471352/</a>   may be an example</p><p><br></p><div><div class="zhistoryRow" style="display:block"><div class="zhistoryDes" style="width: 100%; height: 28px; line-height: 28px; background-color: #E0E5E9; color: #1388FF; text-align: center;" language-data="HistoryOrgTxt">Original Mail</div><div id="zwriteHistoryContainer"><div class="control-group zhistoryPanel"><div class="zhistoryHeader" style="padding: 8px; background-color: #F5F6F8;"><div><strong language-data="HistorySenderTxt">Sender: </strong><span class="zreadUserName"> <sean@dague.net>;</span></div><div><strong language-data="HistoryTOTxt">To: </strong><span class="zreadUserName" style="display: inline;"> <openstack-dev@lists.openstack.org>;</span></div><div><strong language-data="HistoryDateTxt">Date: </strong><span class="">2017/06/16 05:25</span></div><div><strong language-data="HistorySubjectTxt">Subject: </strong><span class="zreadTitle"><strong>Re: [openstack-dev] [all][qa][glance] some recent tempest problems</strong></span></div></div><p class="zhistoryContent"><br></p><div>On 06/15/2017 01:04 PM, Brian Rosmaita wrote:<br>> This isn't a glance-specific problem though we've encountered it quite<br>> a few times recently.<br>> <br>> Briefly, we're gating on Tempest jobs that tempest itself does not<br>> gate on.  This leads to a situation where new tests can be merged in<br>> tempest, but wind up breaking our gate. We aren't claiming that the<br>> added tests are bad or don't provide value; the problem is that we<br>> have to drop everything and fix the gate.  This interrupts our current<br>> work and forces us to prioritize bugs to fix based not on what makes<br>> the most sense for the project given current priorities and resources,<br>> but based on whatever we can do to get the gates un-blocked.<br>> <br>> As we said earlier, this situation seems to be impacting multiple projects.<br>> <br>> One solution for this is to change our gating so that we do not run<br>> any Tempest jobs against Glance repositories that are not also gated<br>> by Tempest.  That would in theory open a regression path, which is why<br>> we haven't put up a patch yet.  Another way this could be addressed is<br>> by the Tempest team changing the non-voting jobs causing this<br>> situation into voting jobs, which would prevent such changes from<br>> being merged in the first place.  The key issue here is that we need<br>> to be able to prioritize bugs based on what's most important to each<br>> project.<br>> <br>> We want to be clear that we appreciate the work the Tempest team does.<br>> We abhor bugs and want to squash them too.  The problem is just that<br>> we're stretched pretty thin with resources right now, and being forced<br>> to prioritize bug fixes that will get our gate un-blocked is<br>> interfering with our ability to work on issues that may have a higher<br>> impact on end users.<br>> <br>> The point of this email is to find out whether anyone has a better<br>> suggestion for how to handle this situation.<br><br>It would be useful to provide detailed examples. Everything is trade<br>offs, and having the conversation in the abstract is very difficult to<br>understand those trade offs.<br><br>    -Sean<br><br>-- <br>Sean Dague<br>http://dague.net<br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></div><p><br></p></div></div></div></div><p><br></p> </div>