<div dir="ltr"><div>FWIW, we tried to reproduce the bug on fresh environments and failed at it (in other words, the deployment succeeds). We've also noticed that the vmware-dvs plugin team has encountered the same bug [0]. If they can't managed to reproduce the issue either, my guess would be that we faced a transient problem with the remote package repositories.<br></div>BR,<br>Simon<br>[0] <a href="https://bugs.launchpad.net/fuel-plugins/+bug/1514043">https://bugs.launchpad.net/fuel-plugins/+bug/1514043</a><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 6, 2015 at 11:38 AM, Simon Pasquier <span dir="ltr"><<a href="mailto:spasquier@mirantis.com" target="_blank">spasquier@mirantis.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"><div dir="ltr"><div><div>Hello,<br><br>While testing LMA with MOS 7.0, we got apt-get crashing and failing the deployment. The details are in the LP bug [0], the TL;DR version is that when more repositories are added (hence more packages), there is a risk that apt-get commands fail badly when trying to remap memory.<br><br>The core issue should be fixed in apt or glibc but in the mean time, increasing the APT::Cache-Start value makes the issue go way. This is what we're going to do with the LMA plugin but since it's independent of LMA, maybe it needs to be addressed at the Fuel level?<br><br></div>BR,<br></div>Simon<br><div><div><br>[0] <a href="https://bugs.launchpad.net/lma-toolchain/+bug/1513539" target="_blank">https://bugs.launchpad.net/lma-toolchain/+bug/1513539</a><br></div></div></div>
</blockquote></div><br></div></div>