fuel-dev team mailing list archive

[Bogdan Dobrelya <bdobrelia@xxxxxxxxxxxx>]

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