<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 20, 2017 at 3:11 AM, Ian Wienand <span dir="ltr"><<a href="mailto:iwienand@redhat.com" target="_blank">iwienand@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_-4658998160418178481gmail-">On 09/20/2017 09:30 AM, David Moreau Simard wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
At what point does it become beneficial to build more than one image per OS<br>
that is more aggressively tuned/optimized for a particular purpose ?<br>
</blockquote>
<br></span>
... and we can put -dsvm- in the jobs names to indicate it should run<br>
on these nodes :)<br>
<br>
Older hands than myself will remember even more issues, but the<br>
"thicker" the base-image has been has traditionally just lead to a lot<br>
more corners for corner-cases can hide in.  We saw this all the time<br>
with "snapshot" images where we'd be based on upstream images that<br>
would change ever so slightly and break things, leading to<br>
diskimage-builder and the -minimal build approach.<br>
<br>
That said, in a zuulv3 world where we are not caching all git and have<br>
considerably smaller images, a nodepool that has a scheduler that<br>
accounts for flavor sizes and could conceivably understand similar for<br>
images, and where we're building with discrete elements that could<br>
"bolt-on" things like a list-of-packages install sanely to daily<br>
builds ... it's not impossible to imagine.<span class="gmail-m_-4658998160418178481gmail-HOEnZb"><font color="#888888"><br>
<br>
-i</font></span></blockquote><div><br></div><div>The problem is these package install steps are not really I/O bottle-necked in most cases,</div><div>even with a regular DSL speed you can  frequently see<br>the decompress and the post config steps takes more time.</div><div><br></div><div>The site-local cache/mirror has visible benefit, but does not eliminates the issues.<br></div><div><br></div><div>The main enemy is the single threaded CPU intensive operation in most install/config related script,<br></div><div>the 2th most common issue is serially requesting high latency steps, which does not reaches neither<br></div><div>the CPU or I/O possibilities at the end.<br></div><div><br></div><div>The fat images are generally cheaper even if your cloud has only 1Gb Ethernet for image transfer.</div><div>You gain more by baking the packages into the image than the 1GbE can steal from you, because<br></div><div>you also save time what would be loosen on CPU intensive operations or from random disk access.</div><div><br></div><div>It is safe to add all distro packages used  by devstack to the cloud image.</div><div><br></div><div>Historically we had issues with some base image packages which presence changed the</div><div>behavior of some component ,for example firewalld vs. libvirt (likely an already solved issue),<br> these packages got explicitly removed by devstack in case of necessary.</div><div>Those packages not requested by devstack !<br></div><div><br></div><div>Fedora/Centos also has/had issues with overlapping with pypi packages on main filesystem,</div><div>(too long story, pointing fingers ..) , generally not a good idea to add packages from pypi to<br></div><div>an image which content might be overridden by the distro's package manager.<br></div><div><br></div><div>The distribution package install time delays the gate response,<br>when the slowest ruining job delayed by this, than the whole response is delayed.</div><br>It Is an user facing latency issue, which should be solved even if the cost would be higher.<br></div><div class="gmail_quote"><div><br></div><div>The image building was the good old working solution and unless the image build<br> become a super expensive thing, this is still the best option.</div><div> <br>site-local mirror also expected to help making the image build step(s) faster and safer.<br></div><div><br></div><div>The other option is the ready scripts.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_-4658998160418178481gmail-HOEnZb"><div class="gmail-m_-4658998160418178481gmail-h5"><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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div></div>