<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 1, 2018 at 5:47 AM Derek Higgins <<a href="mailto:derekh@redhat.com">derekh@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 31 Oct 2018 at 17:22, Alex Schultz <<a href="mailto:aschultz@redhat.com" target="_blank">aschultz@redhat.com</a>> wrote:<br>
><br>
> Hey everyone,<br>
><br>
> Based on previous emails around this[0][1], I have proposed a possible<br>
> reducing in our usage by switching the scenario001--011 jobs to<br>
> non-voting and removing them from the gate[2]. This will reduce the<br>
> likelihood of causing gate resets and hopefully allow us to land<br>
> corrective patches sooner.  In terms of risks, there is a risk that we<br>
> might introduce breaking changes in the scenarios because they are<br>
> officially non-voting, and we will still be gating promotions on these<br>
> scenarios.  This means that if they are broken, they will need the<br>
> same attention and care to fix them so we should be vigilant when the<br>
> jobs are failing.<br>
><br>
> The hope is that we can switch these scenarios out with voting<br>
> standalone versions in the next few weeks, but until that I think we<br>
> should proceed by removing them from the gate.  I know this is less<br>
> than ideal but as most failures with these jobs in the gate are either<br>
> timeouts or unrelated to the changes (or gate queue), they are more of<br>
> hindrance than a help at this point.<br>
><br>
> Thanks,<br>
> -Alex<br>
<br>
While on the topic of reducing the CI footprint<br>
<br>
something worth considering when pushing up a string of patches would<br>
be to remove a bunch of the check jobs at the start of the patch set.<br>
<br>
e.g. If I'm working on t-h-t and have a series of 10 patches, while<br>
looking for feedback I could remove most of the jobs from<br>
zuul.d/layout.yaml in patch 1 so all 10 patches don't run the entire<br>
suite of CI jobs. Once it becomes clear that the patchset is nearly<br>
ready to merge, I change patch 1 leave zuul.d/layout.yaml as is.<br>
<br>
I'm not suggesting everybody does this but anybody who tends to push<br>
up multiple patch sets together could consider it to not tie up<br>
resources for hours.<br>
<br>
><br>
> [0] <a href="http://lists.openstack.org/pipermail/openstack-dev/2018-October/136141.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2018-October/136141.html</a><br>
> [1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2018-October/135396.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2018-October/135396.html</a><br>
> [2] <a href="https://review.openstack.org/#/q/topic:reduce-tripleo-usage+(status:open+OR+status:merged)" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/topic:reduce-tripleo-usage+(status:open+OR+status:merged)</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></blockquote><div><br></div><div>Greetings,</div><div><br></div><div>Just a quick update..  The TripleO CI team is just about done migrating multinode scenario 1-4 jobs to the SingleNode job.  This update and a few other minor changes have moved the needle with regards to TripleO's upstream resource consumption.</div><div><br></div><div>In October of 2017 we had the following footprint..</div><div>tripleo: 111256883.96s, 52.45%  [1]<br></div><div><br></div><div>Today our footprint is now..</div><div>tripleo: 313097590.30s, 36.70% [2]<br></div><div><br></div><div>We are still working the issue and we should see further improvement over the next couple months.  I'll update the list again at the end of Stein.</div><div><br></div><div>Thanks to Clark, Doug, Alex, Emilien and Juan for the work to make this happen!!</div><div>Also thank you to the folks on the TripleO-CI team, you know who you are :)</div><div><br></div><div>[1] <a href="http://paste.openstack.org/show/733644/">http://paste.openstack.org/show/733644/</a></div><div>[2] <a href="http://paste.openstack.org/show/743188/">http://paste.openstack.org/show/743188/</a></div><div> </div></div></div></div></div></div></div>