<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 28, 2020 at 7:24 AM Emilien Macchi <<a href="mailto:emilien@redhat.com">emilien@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"><div dir="ltr"><div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 28, 2020 at 9:20 AM Alex Schultz <<a href="mailto:aschultz@redhat.com" target="_blank">aschultz@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 Tue, Jul 28, 2020 at 7:13 AM Emilien Macchi <<a href="mailto:emilien@redhat.com" target="_blank">emilien@redhat.com</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Jul 27, 2020 at 5:27 PM Wesley Hayutin <<a href="mailto:whayutin@redhat.com" target="_blank">whayutin@redhat.com</a>> wrote:<br>
>><br>
>> FYI...<br>
>><br>
>> If you find your jobs are failing with an error similar to [1], you have been rate limited by <a href="http://docker.io" rel="noreferrer" target="_blank">docker.io</a> via the upstream mirror system and have hit [2].  I've been discussing the issue w/ upstream infra, rdo-infra and a few CI engineers.<br>
>><br>
>> There are a few ways to mitigate the issue however I don't see any of the options being completed very quickly so I'm asking for your patience while this issue is socialized and resolved.<br>
>><br>
>> For full transparency we're considering the following options.<br>
>><br>
>> 1. move off of <a href="http://docker.io" rel="noreferrer" target="_blank">docker.io</a> to <a href="http://quay.io" rel="noreferrer" target="_blank">quay.io</a><br>
><br>
><br>
> <a href="http://quay.io" rel="noreferrer" target="_blank">quay.io</a> also has API rate limit:<br>
> <a href="https://docs.quay.io/issues/429.html" rel="noreferrer" target="_blank">https://docs.quay.io/issues/429.html</a><br>
><br>
> Now I'm not sure about how many requests per seconds one can do vs the other but this would need to be checked with the quay team before changing anything.<br>
> Also <a href="http://quay.io" rel="noreferrer" target="_blank">quay.io</a> had its big downtimes as well, SLA needs to be considered.<br>
><br>
>> 2. local container builds for each job in master, possibly ussuri<br>
><br>
><br>
> Not convinced.<br>
> You can look at CI logs:<br>
> - pulling / updating / pushing container images from <a href="http://docker.io" rel="noreferrer" target="_blank">docker.io</a> to local registry takes ~10 min on standalone (OVH)<br>
> - building containers from scratch with updated repos and pushing them to local registry takes ~29 min on standalone (OVH).<br>
><br>
>><br>
>> 3. parent child jobs upstream where rpms and containers will be build and host artifacts for the child jobs<br>
><br>
><br>
> Yes, we need to investigate that.<br>
><br>
>><br>
>> 4. remove some portion of the upstream jobs to lower the impact we have on 3rd party infrastructure.<br>
><br>
><br>
> I'm not sure I understand this one, maybe you can give an example of what could be removed?<br>
<br>
We need to re-evaulate our use of scenarios (e.g. we have two<br>
scenario010's both are non-voting).  There's a reason we historically<br>
didn't want to add more jobs because of these types of resource<br>
constraints.  I think we've added new jobs recently and likely need to<br>
reduce what we run. Additionally we might want to look into reducing<br>
what we run on stable branches as well.<br>
</blockquote></div><br clear="all"></div><div>Oh... removing jobs (I thought we would remove some steps of the jobs).</div><div>Yes big +1, this should be a continuous goal when working on CI, and always evaluating what we need vs what we run now.</div><div><br></div><div>We should look at:</div><div>1) services deployed in scenarios that aren't worth testing (e.g. deprecated or unused things) (and deprecate the unused things)</div><div>2) jobs themselves (I don't have any example beside scenario010 but I'm sure there are more).<br></div><div>-- <br><div dir="ltr"><div dir="ltr">Emilien Macchi<br></div></div></div></div></blockquote><div><br></div><div>Thanks Alex, Emilien</div><div><br></div><div>+1 to reviewing the catalog and adjusting things on an ongoing basis.  </div><div><br></div><div>All.. it looks like the issues with <a href="http://docker.io">docker.io</a> were more of a flare up than a change in <a href="http://docker.io">docker.io</a> policy or infrastructure [2].  The flare up started on July 27 8am utc and ended on July 27 17:00 utc, see screenshots.</div><div><br></div><div>I've socialized the issue with the CI team and some ways to reduce our reliance on <a href="http://docker.io">docker.io</a> or any public registry.  Sagi and I have a draft design that we'll share on this list after a first round of a POC.  We also thought we'd leverage Emilien's awesome work [1] to build containers locally in standalone for widely to reduce our traffic to <a href="http://docker.io">docker.io</a> and upstream proxies.</div><div><br></div><div>TLDR, feel free to recheck and wf.  Thanks for your patience!!</div><div><br></div><div>[1] <a href="https://review.opendev.org/#/q/status:open++topic:dos_docker.io">https://review.opendev.org/#/q/status:open++topic:dos_docker.io</a></div><div>[2] <a href="http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22429%20Client%20Error%3A%20Too%20Many%20Requests%20for%20url%3A%5C%22%20AND%20voting%3A1">link to logstash query be sure to change the time range</a></div><div><br></div></div></div>