Thread Previous • Date Previous • Date Next • Thread Next |
Dmitriy, I support your point on overcrowded Fuel settings (for example - why the hell do we have scheduler selector there?), BUT - CPU overcommit rate to me looks like something that cloud lifecycle management app should be in charge of. It's an important decision, closely coupled with decisions on how many controllers to have, what hypervisor to use and how to map logical networks to physical segments. 2 examples where not having it exposed to user can harm: 1) User plans capacity using BOM calculator <http://www.mirantis.com/openstack-services/bom-calculator/> (or any of Mirantis or Rackspace blog posts) and Fuel gives no way of applying CPU overcommit decision. User perceives Fuel as not flexible/powerful enough. 2) User deploys cloud w/ Fuel and adjusts CPU overcommit as a post-install action in nova.conf. One of controllers fail over time and has to be replaced. User add new controller, and gets inconsistent CPU overcommit settings across 3 controllers OR all 3 controllers reset into default Fuel overcommit rate (I'm not sure if adding a controller will cause all controllers to redeploy w/ current Fuel release). Both options are not acceptable for production cloud. We need to think about the consistency of user experience, with all our tools - bom calculator, Fuel, etc. The more critical aspects we take out to documentation/post-install - the less value users will see in Fuel --- Regards, Dmitriy On Tue, Jun 24, 2014 at 12:02 AM, Dmitry Borodaenko < dborodaenko@xxxxxxxxxxxx> wrote: > Adding a configuration variable that can easily be changed after > deployment is completed into Fuel is a slippery slope, you risk > spamming the already overcrowded Fuel settings page with dozens of > trivial (and not so trivial) options from every OpenStack component. > > Here's my version of the story with the CPU overallocation ratio: > 1) blueprint scheduler-config-improvements proposed to change this > ratio from 16 (default from puppet-nova) to 1 > 2) this was merged for 5.0 as https://review.openstack.org/90106 > 3) as soon as above was merged, we found out that this broke CI (where > every compute node is a VM with 1 allocated core), so Vladimir changed > that ratio to 8 in https://review.openstack.org/90426 > 4) when backporting 90106 to 4.1.1, I found that it needed 90426 to > pass CI and included both patches in the backport (as explained in the > backport's commit message) > > As a result, both 4.1.1 and 5.0 (as well as upcoming 5.1) set > cpu_allocation_ratio to 8. I can't find any mention of value 4 in any > of the branches. Yes, this value is a bit on the aggressive side, but > given how easy it is to change, I don't think it's worth the trouble > of adding it to Fuel's Web UI. Besides, Fuel is a deployment and life > cycle managemt tool, not a swiss army knife configuration front-end. > If you want a GUI to tweak performance settings, Horizon dashboard > seems like a more appropriate place. > > > > On Mon, Jun 23, 2014 at 11:49 AM, Dmitriy Novakovskiy > <dnovakovskiy@xxxxxxxxxxxx> wrote: > > I would strongly advocate allowing user to specify overcommit rate for > CPU > > (not RAM) We can either: > > > > a) show a drop-down with some suggested values > > b) add a field for user input, with validation of input and text > guidelines > > nearby > > > > --- > > Regards, > > Dmitriy > > > > > > On Mon, Jun 23, 2014 at 9:43 PM, Andrey Danin <adanin@xxxxxxxxxxxx> > wrote: > >> > >> It's strange. We have a closed blueprint > >> > https://blueprints.launchpad.net/fuel/+spec/scheduler-config-improvements > >> According it we implemented all ones for every ratio in 5.0 ( changeset > >> https://review.openstack.org/#/c/90106 ) But when it was backported to > 4.1.1 > >> ( https://review.openstack.org/97998 ) the cpu ratio become 4. It was > done > >> by Vova Kuklin in https://review.openstack.org/90426 and actually both > 5.0 > >> and 4.1.1 have 8/1/1 ratios, whereas 4.1 and older have default ratios > >> 16/1.5/1 CPU/RAM/DISK ratios. > >> > >> Maybe we need to allow user to set up ratios manually. > >> > >> > >> On Mon, Jun 23, 2014 at 10:16 PM, Dmitriy Novakovskiy > >> <dnovakovskiy@xxxxxxxxxxxx> wrote: > >>> > >>> 8 is kind of aggressive :) and also different from BOM calculator. > Maybe > >>> it makes sense to make it configurable on GUI? > >>> > >>> --- > >>> Regards, > >>> Dmitriy > >>> > >>> > >>> On Mon, Jun 23, 2014 at 8:26 PM, Andrey Danin <adanin@xxxxxxxxxxxx> > >>> wrote: > >>>> > >>>> deployment/puppet/osnailyfacter/manifests/cluster_ha.pp:477: > >>>> cpu_allocation_ratio => '8.0', > >>>> deployment/puppet/osnailyfacter/manifests/cluster_ha.pp:478: > >>>> disk_allocation_ratio => '1.0', > >>>> deployment/puppet/osnailyfacter/manifests/cluster_ha.pp:479: > >>>> ram_allocation_ratio => '1.0', > >>>> deployment/puppet/osnailyfacter/manifests/cluster_simple.pp:299: > >>>> cpu_allocation_ratio => '8.0', > >>>> deployment/puppet/osnailyfacter/manifests/cluster_simple.pp:300: > >>>> disk_allocation_ratio => '1.0', > >>>> deployment/puppet/osnailyfacter/manifests/cluster_simple.pp:301: > >>>> ram_allocation_ratio => '1.0', > >>>> > >>>> > >>>> > >>>> On Mon, Jun 23, 2014 at 9:00 PM, Dmitriy Novakovskiy > >>>> <dnovakovskiy@xxxxxxxxxxxx> wrote: > >>>>> > >>>>> Hy guys, > >>>>> > >>>>> Can you plz let me know what overcommit rates does Fuel use for CPU > and > >>>>> RAM when configuring Nova? thanks > >>>>> --- > >>>>> Regards, > >>>>> Dmitriy > >>>>> > >>>>> -- > >>>>> Mailing list: https://launchpad.net/~fuel-dev > >>>>> Post to : fuel-dev@xxxxxxxxxxxxxxxxxxx > >>>>> Unsubscribe : https://launchpad.net/~fuel-dev > >>>>> More help : https://help.launchpad.net/ListHelp > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Andrey Danin > >>>> adanin@xxxxxxxxxxxx > >>>> skype: gcon.monolake > >>> > >>> > >> > >> > >> > >> -- > >> Andrey Danin > >> adanin@xxxxxxxxxxxx > >> skype: gcon.monolake > > > > > > > > -- > > Mailing list: https://launchpad.net/~fuel-dev > > Post to : fuel-dev@xxxxxxxxxxxxxxxxxxx > > Unsubscribe : https://launchpad.net/~fuel-dev > > More help : https://help.launchpad.net/ListHelp > > > > > > -- > Dmitry Borodaenko >
Thread Previous • Date Previous • Date Next • Thread Next |