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:
- yes, it needs time to bootstrap admin node - As soon as I have message that master node is installed, I immediately open 10.20.0.2:8000 and try to generate diag snapshot. And it is failed. - If I wait a few more minutes, and try again - it is passed. It actually seems to me that we simply still do not have https://bugs.launchpad.net/fuel/+bug/1315865 fixed, I'll add more details there as well as logs. When I checked logs, I saw: - for about a minute, astute was not able to connect to MQ. It means it is still started before MQ is ready? - shotgun -c /tmp/dump_config >> /var/log/dump.log 2>&1 && cat /var/www/nailgun/dump/last returned 1 When I tried to run diag_snapshot for a second time, the command above succeeded with 0 return code. 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. 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. Thanks, On Sat, May 10, 2014 at 1:04 AM, Vladimir Kuklin <vkuk...@mirantis.com>wrote: > Hi all > > We are still experiencing some issues with master node bootstrapping after > moving to container-based installation. > > 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. > > I have several suggestions: > > 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. > 2) Run system tests with non-containerized environment (env variable > PRODUCTION=prod set) > 3) Split our system tests in that way not allowing more than 2 master > nodes to bootstrap simulteneously on the single hardware node. > 4) do lrzipping as weak as possible during the development phase and lrzip > it strongly only when we do release > 5) increase bootstrap timeout for the master node in system tests > > > Any input would be appreciated. > > -- > Yours Faithfully, > Vladimir Kuklin, > Fuel Library Tech Lead, > Mirantis, Inc. > +7 (495) 640-49-04 > +7 (926) 702-39-68 > Skype kuklinvv > 45bk3, Vorontsovskaya Str. > Moscow, Russia, > www.mirantis.com <http://www.mirantis.ru/> > www.mirantis.ru > vkuk...@mirantis.com > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Mike Scherbakov #mihgen
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev