All, I've submitted a blueprint on this: https://blueprints.launchpad.net/fuel/+spec/cpu-overcommit-setting
Bogdan, Nice and creative approach, but IMO the question of "how many instances to run" and "what overcommit to use" belongs more to planning/architecture workshop/BOM calculator <http://www.mirantis.com/openstack-services/bom-calculator/> phase. Not only amount of VMs to run on given amount of Compute nodes counts here - also the capability of hypervisor to "juggle" oversubscribed cores (poor in KVM, better in ESXi), the kind of environment (Prod, Dev/Test), the level of tolerance to VM failure, etc. Fuel just need to prompt+allow user to apply decisions made at planning phase to deployment phase. --- Regards, Dmitriy On Tue, Jun 24, 2014 at 2:22 PM, Bogdan Dobrelya <[email protected]> wrote: > On 06/24/2014 01:50 PM, Dmitriy Novakovskiy wrote: > > Andrey, Dmitriy > > > > I've just realized that CPU overcommitment setting is defined not for > > Controllers but for Compute nodes, and may differ on per-node basis. So, > > the 2nd "harm" example that I exposed a few emails ago (with failed and > > redeployed controller resulting in inconsistent overcommitment behavior) > > is irrelevant. > > > > With this in mind, 3rd example is even worse :) > > > > 3) User goes through architecture workshop and capacity planning > > exercise, decides on CPU overcommit rates he/she will use for OpenStack > > cloud. User deploys the cloud with, let's say, 20+ compute nodes. Now, > > w/o CPU overcommit setting on GUI, User will: > > - get a cloud that's inconsistent with decisions made during planning > > - be not aware of this - GUI did not point user to a need of specifying > > this setting > > - be frustrated and put under risk - if the cloud is deployed with real > > workloads the compute nodes will soon become over provisioned and > > unreliable due to default Fuel setting (prod KVM clouds often use > > super-soft overcommit setting, or no overcommit at all) > > - finally - *user will have to MANUALLY specify and maintain overcommit > > setting across 20+ compute nodes.* > > * > > * > > Doesn't sound like a good UX from cloud lifecycle management app :) - > > Fuel will quickly be ditched in favor of config management tool. > > > > So, my proposal on CPU overcommitment setting is following: > > > > - Expose it in Wizard on hypervisor selection screen > > - To simplify things initially - implement the setting as a drop-down > > list, with 2 options: > > -- No CPU overcommitment (1:1) > > -- Light CPU overcommitment (3:1) > > -- Heavy CPU overcommitment (6:1) --- default setting in BOM calculator > > Good point. We could as well evaluate the suggested ratio based on the > user outputs and roles allocation, e.g.: > 1) Q(wizard):"How many running instances your cloud has to maintain?" -> > user specifies 10000 > 2) and there are 100 compute nodes assigned in UI > > then, > - the CPU overcommitment should be evaluated as 10000/100 : 1 > - if the value exceeds the default maximum (16) for OSt, the warning > should be issued in UI notifications (please provide more compute nodes > in order to maintain the desired capacity for running instances) > > > > > > > --- > > Regards, > > Dmitriy > > > > > > On Tue, Jun 24, 2014 at 1:23 PM, Andrey Danin <[email protected] > > <mailto:[email protected]>> wrote: > > > > I think, we can add to openstack.yaml a special tag "advanced" to > > every advanced parameter, and UI can hide all such parameters for > > every group under the button "show more options". Also we can add > > the "expand all hidden options" button at the top of the tab. I > > don't think it's hard to implement. > > > > Let's wait an opinion of UI team. > > > > On Jun 24, 2014 1:58 PM, "Meg McRoberts" <[email protected] > > <mailto:[email protected]>> wrote: > > > > Jesse and others make a very good point. The Settings screen > > has already become a real mess > > that needs to be split up and organized a bit. I'm told that > > the serious restructuring should come > > after we implement the plug-ins scheme (currently planned for > > 6.0). And each section definitely > > needs an "Advanced" section for configurations that aren't > routine. > > > > So do we wait to restructure the "Settings" screen until the > > plug-ins scheme is implemented? I > > think breaking it up into sub-sections would make it more usable > > in the meantime but I don't know > > if it's worth the effort to do that ahead of the plug-ins. > > > > > > On Tue, Jun 24, 2014 at 2:23 AM, Jesse Pretorius > > <[email protected] <mailto:[email protected]>> > > wrote: > > > > On 23 June 2014 23:02, Dmitry Borodaenko > > <[email protected] <mailto:[email protected]>> > > 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. > > > > > > While I agree, the fact of the matter is that Fuel > > facilitates the deployment of configuration to all nodes in > > the environment in a consistent manner. This is essential to > > deploy a reliable and supportable environment. > > > > In order to maintain the simplicity of the UI, but also > > provide access to OpenStack's customisable configuration, > > why not do something like add an 'advanced' button into the > > UI. Under there, the additional options can be provided, and > > things that are already 'Advanced' (like the scheduler, the > > Ceph replication factor, etc) can move under the 'Advanced' > > button for each section. > > > > An additional very beneficial feature in the Advanced > > section would be to allow any arbitrary key-value pairs for > > any settings that a user may wish to deploy into the > > configuration files for the appropriate system (eg: > > nova.conf). The user can be warned that these will not be > > validated and that they are used at the user's own risk. > > This can allow any number of OpenStack underlying features > > to be used without requiring a specific UI for it. > > > > -- > > Mailing list: https://launchpad.net/~fuel-dev > > Post to : [email protected] > > <mailto:[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] > > <mailto:[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] > > <mailto:[email protected]> > > Unsubscribe : https://launchpad.net/~fuel-dev > > More help : https://help.launchpad.net/ListHelp > > > > > > > > > > > -- > 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
