In my opinion it's reasonable to limit expectations on what you can evaluate on virtualbox, and provide appropriate caveats. The truth is that making a virtual machine do everything it needs to do to stay synced in real-time with two or more other virtual machines requires resources. Evaluating Fuel as a deployment tool under virtualbox makes sense, but expecting to get a legitimate evaluation of working (and performant) HA under a severely restricted environment doesn't seem reasonable.
Would a legitimate customer expect to be able to do a thorough evaluation of MOS without using anything more than a single machine with a moderate amount of ram? -Christopher On Thu, Aug 21, 2014 at 4:59 PM, David Easter <[email protected]> wrote: > It has already became nearly impossible to run the default virtualbox > environment (with a cluster size of 3 nodes) on an 8GB system. It would > become challenging if we begin to tax a 16GB system to do this now… > > Are there alternatives or specific tunings that can be done so that the > sizing for a virtualbox trial is different than what is needed for > production or physical server testing? > > Thanks, > > - David J. Easter > Director of Product Management, Mirantis, Inc. > > From: "[email protected]" <[email protected]> > Date: Thursday, August 21, 2014 at 4:29 PM > To: Sergii Golovatiuk <[email protected]>, David Easter > <[email protected]> > Cc: Bogdan Dobrelya <[email protected]>, "[email protected]" > <[email protected]> > Subject: Re: [Fuel-dev] RAM issues with environments > > David, > > FYI - it will impact VirtualBox trials. 3 controllers x 3GB = 9 GB RAM only > for controllers if you run HA. > > Roman > > > On Thu, Aug 21, 2014 at 5:22 AM, Sergii Golovatiuk > <[email protected]> wrote: >> >> +1 for not using debug at CI gates (only BVT) >> +1 for adding atop to our builds as it helps to understand what was wrong >> at that particular time >> +1 for increasing RAM (though we'll try to tune rabbit and Galera). 3GB >> should be enough so we'll be able to run up to 2 environments on 32GB RAM >> servers. >> >> -- >> Best regards, >> Sergii Golovatiuk, >> Skype #golserge >> IRC #holser >> >> >> On Thu, Aug 21, 2014 at 1:25 PM, Bogdan Dobrelya <[email protected]> >> wrote: >>> >>> On 08/21/2014 12:41 PM, Sergii Golovatiuk wrote: >>> > Hi, >>> > >>> > Digging the issue with Galera, I found that our environments have very >>> > high RAM utilization which leads to the problem during environment >>> > deployment. For instance "HA deployment + neutron/GRE" requires almost >>> > 2.6-2.7 GB during deployment >>> > (corosync+mysql+puppet++rabbit+neutron+ovs+openstack services). I found >>> > high swap in/swap out usage during deployment with very high load >>> > average. This creates many sporadic issues with some services. They >>> > time >>> > out in random place making our debugging very hard. I would like to >>> > review our policy for CI environment and increase RAM (at least for bvt >>> > tests) to 3 GB. >>> > >>> > -- >>> > Best regards, >>> > Sergii Golovatiuk, >>> > Skype #golserge >>> > IRC #holser >>> > >>> > >>> >>> I believe we should do at least the following for our CI jobs and bvt >>> tests: >>> 1) Deployment shortcuts: stop deployment abruptly, if any deployment >>> blocker has been met, such as something exceeded given # of retries. >>> That could be done in puppet by overriding 'tries' behavior in exec >>> provider, or at orchestration layer as well. >>> 2) Load management: collect and automatically analyze atop stats (swap >>> rates, load average, io waiters) from jenkins slaves and vm nodes while >>> running the jobs, and stop or freeze some jobs, if some >>> performance-stopper criteria has been met as well. >>> 3) Do not use debug level logging for CI gates, use it only for bvt >>> tests. >>> >>> -- >>> Best regards, >>> Bogdan Dobrelya, >>> Skype #bogdando_at_yahoo.com >>> Irc #bogdando >> >> >> >> -- >> Mailing list: https://launchpad.net/~fuel-dev >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~fuel-dev >> More help : https://help.launchpad.net/ListHelp >> > > > -- > Mailing list: https://launchpad.net/~fuel-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp > -- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
