We should check with our training people to see what they need. For example, any reasonable evaluation of MongoDB (used for Ceilometer) or Zabbix probably requires a lot more resources than people are going to have on their personal machine, but it would be nice if they could configure some sort of minimally-functional version of these on a smaller system just for training purposes.
On Fri, Aug 22, 2014 at 12:12 AM, Sergii Golovatiuk < sgolovat...@mirantis.com> wrote: > Hi, > > I would say we have to update release notes. Even now it's barely possible > to unleash Fuel power on laptop with 8GB of RAM. With 16Gb you may have up > to 5 VMs simulating HA environment. If we limit VM RAM to 2.5 user may have > 5x2.5+1(master node)=13.5 GB which should be enough for demo purposes. > > > -- > Best regards, > Sergii Golovatiuk, > Skype #golserge > IRC #holser > > > On Fri, Aug 22, 2014 at 3:06 AM, Christopher Aedo <ca...@mirantis.com> > wrote: > >> 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 <deas...@mirantis.com> >> 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: "ralekseen...@mirantis.com" <ralekseen...@mirantis.com> >> > Date: Thursday, August 21, 2014 at 4:29 PM >> > To: Sergii Golovatiuk <sgolovat...@mirantis.com>, David Easter >> > <deas...@mirantis.com> >> > Cc: Bogdan Dobrelya <bdobre...@mirantis.com>, " >> fuel-dev@lists.launchpad.net" >> > <fuel-dev@lists.launchpad.net> >> > 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 >> > <sgolovat...@mirantis.com> 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 < >> bdobre...@mirantis.com> >> >> 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 : fuel-dev@lists.launchpad.net >> >> Unsubscribe : https://launchpad.net/~fuel-dev >> >> More help : https://help.launchpad.net/ListHelp >> >> >> > >> > >> > -- >> > Mailing list: https://launchpad.net/~fuel-dev >> > Post to : fuel-dev@lists.launchpad.net >> > Unsubscribe : https://launchpad.net/~fuel-dev >> > More help : https://help.launchpad.net/ListHelp >> > >> > > > -- > Mailing list: https://launchpad.net/~fuel-dev > Post to : fuel-dev@lists.launchpad.net > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp > >
-- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
