<div dir="ltr"><div><div>decompressing those registry tar.gz takes ~0.5 min on 2.2 GHz CPU. </div><br>Fully pulling all container takes something like ~4.5 min (from localhost, one leaf request at a time), <br>but on the gate vm  we usually have 4 core,<br> so it is possible to go bellow 2 min with better pulling strategy,<br> unless we hit some disk limit.<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 23, 2017 at 5:12 AM, Michał Jastrzębski <span dir="ltr"><<a href="mailto:inc007@gmail.com" target="_blank">inc007@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 22 September 2017 at 17:21, Paul Belanger <<a href="mailto:pabelanger@redhat.com">pabelanger@redhat.com</a>> wrote:<br>
> On Fri, Sep 22, 2017 at 02:31:20PM +0000, Jeremy Stanley wrote:<br>
>> On 2017-09-22 15:04:43 +0200 (+0200), Attila Fazekas wrote:<br>
>> > "if DevStack gets custom images prepped to make its jobs<br>
>> > run faster, won't Triple-O, Kolla, et cetera want the same and where<br>
>> > do we draw that line?). "<br>
>> ><br>
>> > IMHO we can try to have only one big image per distribution,<br>
>> > where the packages are the union of the packages requested by all team,<br>
>> > minus the packages blacklisted by any team.<br>
>> [...]<br>
>><br>
>> Until you realize that some projects want packages from UCA, from<br>
>> RDO, from EPEL, from third-party package repositories. Version<br>
>> conflicts mean they'll still spend time uninstalling the versions<br>
>> they don't want and downloading/installing the ones they do so we<br>
>> have to optimize for one particular set and make the rest<br>
>> second-class citizens in that scenario.<br>
>><br>
>> Also, preinstalling packages means we _don't_ test that projects<br>
>> actually properly declare their system-level dependencies any<br>
>> longer. I don't know if anyone's concerned about that currently, but<br>
>> it used to be the case that we'd regularly add/break the package<br>
>> dependency declarations in DevStack because of running on images<br>
>> where the things it expected were preinstalled.<br>
>> --<br>
>> Jeremy Stanley<br>
><br>
> +1<br>
><br>
> We spend a lot of effort trying to keep the 6 images we have in nodepool working<br>
> today, I can't imagine how much work it would be to start adding more images per<br>
> project.<br>
><br>
> Personally, I'd like to audit things again once we roll out zuulv3, I am sure<br>
> there are some tweaks we could make to help speed up things.<br>
<br>
</div></div>I don't understand, why would you add images per project? We have all<br>
the images there.. What I'm talking about is to leverage what we'll<br>
have soon (registry) to lower time of gates/DIB infra requirements<br>
(DIB would hardly need to refresh images...)<br>
<div class="HOEnZb"><div class="h5"><br>
> ______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>