<div dir="ltr"><div>I have overlay2 and super fast disk I/O (memory cheat + SSD),<br></div><div>just the CPU freq is not high. The CPU is a Broadwell<br> and actually it has lot more core (<span class="gmail-value"><span>E5-2630V4</span></span>). Even a 5 year old gamer CPU can be 2 times<br></div><div>faster on a single core, but cannot compete with all of the cores ;-)<br></div><div><br></div><div>This machine have seen faster setup time,  but I'll return to this in an another topic.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 26, 2017 at 6:16 PM, 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"><span class="">On 26 September 2017 at 07:34, Attila Fazekas <<a href="mailto:afazekas@redhat.com">afazekas@redhat.com</a>> wrote:<br>
> decompressing those registry tar.gz takes ~0.5 min on 2.2 GHz CPU.<br>
><br>
> Fully pulling all container takes something like ~4.5 min (from localhost,<br>
> 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>
<br>
</span>Check your $docker info. If you kept defaults, storage driver will be<br>
devicemapper on loopback, which is awfully slow and not very reliable.<br>
Overlay2 is much better and should speed things up quite a bit. For me<br>
deployment of 5 node openstack on vms similar to gate took 6min (I had<br>
registry available in same network). Also if you pull single image it<br>
will download all base images as well, so next one will be<br>
significantly faster.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On Sat, Sep 23, 2017 at 5:12 AM, Michał Jastrzębski <<a href="mailto:inc007@gmail.com">inc007@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On 22 September 2017 at 17:21, Paul Belanger <<a href="mailto:pabelanger@redhat.com">pabelanger@redhat.com</a>><br>
>> 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<br>
>> >> > 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<br>
>> > working<br>
>> > today, I can't imagine how much work it would be to start adding more<br>
>> > images per<br>
>> > project.<br>
>> ><br>
>> > Personally, I'd like to audit things again once we roll out zuulv3, I am<br>
>> > sure<br>
>> > there are some tweaks we could make to help speed up things.<br>
>><br>
>> 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>
>><br>
>> ><br>
>> > ______________________________<wbr>______________________________<wbr>______________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> > <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>
><br>
><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>
><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>