fuel-dev team mailing list archive

[Dmitriy Novakovskiy <dnovakovskiy@xxxxxxxxxxxx>]

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 <bdobrelia@xxxxxxxxxxxx>
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 <adanin@xxxxxxxxxxxx
> > <mailto:adanin@xxxxxxxxxxxx>> 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" <mmcroberts@xxxxxxxxxxxx
> >     <mailto:mmcroberts@xxxxxxxxxxxx>> 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
> >         <jesse.pretorius@xxxxxxxxx <mailto:jesse.pretorius@xxxxxxxxx>>
> >         wrote:
> >
> >             On 23 June 2014 23:02, Dmitry Borodaenko
> >             <dborodaenko@xxxxxxxxxxxx <mailto: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.
> >
> >
> >             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     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >             <mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>
> >             Unsubscribe : https://launchpad.net/~fuel-dev
> >             More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
> >         --
> >         Mailing list: https://launchpad.net/~fuel-dev
> >         Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >         <mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>
> >         Unsubscribe : https://launchpad.net/~fuel-dev
> >         More help   : https://help.launchpad.net/ListHelp
> >
> >
> >     --
> >     Mailing list: https://launchpad.net/~fuel-dev
> >     Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >     <mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>
> >     Unsubscribe : https://launchpad.net/~fuel-dev
> >     More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
> >
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Skype #bogdando_at_yahoo.com
> Irc #bogdando
>