<div dir="ltr">It is not related to RAM or CPU. I run installation on my Mac with 1Gb of RAM for master node, and experience the following:<div><ul><li>yes, it needs time to bootstrap admin node</li><li>As soon as I have message that master node is installed, I immediately open <a href="http://10.20.0.2:8000" target="_blank">10.20.0.2:8000</a> and try to generate diag snapshot. And it is failed.</li>
<li>If I wait a few more minutes, and try again - it is passed.</li></ul><div>It actually seems to me that we simply still do not have <a href="https://bugs.launchpad.net/fuel/+bug/1315865" target="_blank">https://bugs.launchpad.net/fuel/+bug/1315865</a> fixed, I'll add more details there as well as logs.</div>
</div><div><br></div><div>When I checked logs, I saw:</div><div><ul><li>for about a minute, astute was not able to connect to MQ. It means it is still started before MQ is ready?</li><li><font face="courier new, monospace">shotgun -c /tmp/dump_config >> /var/log/dump.log 2>&1 && cat /var/www/nailgun/dump/last </font><font face="arial, helvetica, sans-serif">returned 1</font></li>
</ul>When I tried to run diag_snapshot for a second time, the command above succeeded with 0 return code.</div><div><br></div><div>So it obviously needs further debugging and in my opinion even if we need to increase VCPU or RAM, then no more than 2 VCPU / 2 Gb.<br>
</div><div><br></div><div>Vladimir, as you and Matt were changing the code which should run containers in a certain order, I'm looking forward to hear from both of you suggestions on where and how we should hack it.</div>
<div><br></div><div>Thanks,</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 10, 2014 at 1:04 AM, Vladimir Kuklin <span dir="ltr"><<a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all<div><br></div><div>We are still experiencing some issues with master node bootstrapping after moving to container-based installation.</div>
<div><br></div><div>First of all, these issues are related to our system tests. We have rather small nodes running as master node - only 1 GB of RAM and 1 virtual CPU. As we are using strongly lrzipped archive, this seems quite not enough and leads to timeouts during deployment of the master node.</div>
<div><br></div><div>I have several suggestions:</div><div><br></div><div>1) Increase amount of RAM for master node to at least 8 Gigabytes (or do some pci virtual memory hotplug during master node bootstrapping) and add additional vCPU for the master node.</div>
<div>2) Run system tests with non-containerized environment (env variable PRODUCTION=prod set)</div><div>3) Split our system tests in that way not allowing more than 2 master nodes to bootstrap simulteneously on the single hardware node.</div>
<div>4) do lrzipping as weak as possible during the development phase and lrzip it strongly only when we do release </div><div>5) increase bootstrap timeout for the master node in system tests</div><div><br></div><div><br>
</div><div>Any input would be appreciated.</div><div><div><br></div>-- <br><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>
Skype kuklinvv<br>
45bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div>
</div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Mike Scherbakov<br>#mihgen<br><br>
</div></div>