<div dir="ltr"><br>> The reality is you're just going to have to triage this and be a *lot*<br>> more specific with issues.  I find opening an etherpad and going<br>> through the failures one-by-one helpful (e.g. I keep [2] for centos<br>> jobs I'm interested in).<br>><br>> Looking at the top of the console.html log you'll have the host and<br>> provider/region stamped in there.  If it's timeouts or network issues,<br>> reporting to infra the time, provider and region of failing jobs will<br>> help.  If it's network issues similar will help.  Finding patterns is<br>> the first step to understanding what needs fixing.<br>><div>Here [1] I collect some fail records from gate<div>As we can tell, most of environments set-up becomes really slow and failed at some point with time out error.</div><div>In [1] I collect information for failed node. Hope you can find any clue from it.</div><div> <br><div><br></div><div>[1] <a href="https://etherpad.openstack.org/p/heat-gate-fail-2017-08">https://etherpad.openstack.org/p/heat-gate-fail-2017-08</a></div></div></div><div><br>> If it's due to issues with remote transfers, we can look at either<br>> adding specific things to mirrors (containers, images, packages are<br>> all things we've added recently) or adding a caching reverse-proxy for<br>> them ([3],[4] some examples).<br>><br>> Questions in #openstack-infra will usually get a helpful response too<br>><br>> Good luck :)<br>><br>> -i<br>><br>> [1] <a href="https://bugs.launchpad.net/openstack-gate/+bug/1708707/">https://bugs.launchpad.net/openstack-gate/+bug/1708707/</a><br>> [2] <a href="https://etherpad.openstack.org/p/centos7-dsvm-triage">https://etherpad.openstack.org/p/centos7-dsvm-triage</a><br>> [3] <a href="https://review.openstack.org/491800">https://review.openstack.org/491800</a><br>> [4] <a href="https://review.openstack.org/491466">https://review.openstack.org/491466</a><br><br><br></div></div>