fuel-dev team mailing list archive

[Bogdan Dobrelya <bdobrelia@xxxxxxxxxxxx>]

On 06/24/2014 10:49 PM, Dmitriy Novakovskiy wrote:
> David,
> 
>     /I created an etherpad with the additional requirements
>     (https://etherpad.openstack.org/p/cpu-overcommit-setting) but don’t
>     have rights to set it as the URL for the specification.  If you or
>     an admin could do that, it’d be appreciated./
> 
> 
> Done - added your etherpad as a full spec to BP:
> https://blueprints.launchpad.net/fuel/+spec/cpu-overcommit-setting
> 
>     /With these expectations, you would need to have the parameter be on
>     the Settings tab not (just) the Deployment Wizard. /
> 
> 
> Got it, makes sense. It should be on both screens. 
> 
>     / Also, currently the only way to reactivate the Settings Tab today
>     and “re-apply” is to reset the environment – I.e. delete the
>     existing environment and re-deploy with the modified
>     settings/parameters.   That may be a bit heavy handed for just
>     changing the overcommit value, so we may need a second blueprint
>     that would enable settings to be changed from Fuel without deleting
>     and redeploying the environment… /
> 
> 
> Got it. Well, IMO it calls for us to think through some key concepts,
> what Fuel should/should not be able to do and enforce... Ability to
> adjust CPU overcommit rate on post-deployment phases will be useful, but
> not pri-1. I just thought that UI+engine already supports it.

I believe that would be a common practice while scaling the cloud
horizontally. Every time a cloud admin adds new compute node(s), he or
she might want to update the overcom. ratio for *all* compute nodes as
well. And it would be very neat if Fuel UI could provide it.

> 
> ---
> Regards,
> Dmitriy
> 
> 
> On Tue, Jun 24, 2014 at 10:36 PM, David Easter <deaster@xxxxxxxxxxxx
> <mailto:deaster@xxxxxxxxxxxx>> wrote:
> 
>     Thanks.  With these expectations, you would need to have the
>     parameter be on the Settings tab not (just) the Deployment Wizard.
>      Having it only in the deployment wizard would mean you couldn’t
>     modify it later and that it wouldn’t be reflected in the UI.   Also,
>     currently the only way to reactivate the Settings Tab today and
>     “re-apply” is to reset the environment – I.e. delete the existing
>     environment and re-deploy with the modified settings/parameters.  
>     That may be a bit heavy handed for just changing the overcommit
>     value, so we may need a second blueprint that would enable settings
>     to be changed from Fuel without deleting and redeploying the
>     environment… 
> 
>     I created an etherpad with the additional requirements
>     (https://etherpad.openstack.org/p/cpu-overcommit-setting) but don’t
>     have rights to set it as the URL for the specification.  If you or
>     an admin could do that, it’d be appreciated.
> 
>     Thanks,
> 
>     - David J. Easter
>       Director of Product Management, Mirantis
> 
>     From: Dmitriy Novakovskiy <dnovakovskiy@xxxxxxxxxxxx
>     <mailto:dnovakovskiy@xxxxxxxxxxxx>>
>     Date: Tuesday, June 24, 2014 at 11:54 AM
>     To: David Easter <deaster@xxxxxxxxxxxx <mailto:deaster@xxxxxxxxxxxx>>
>     Cc: Bogdan Dobrelya <bdobrelia@xxxxxxxxxxxx
>     <mailto:bdobrelia@xxxxxxxxxxxx>>, fuel-dev
>     <fuel-dev@xxxxxxxxxxxxxxxxxxx
>     <mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>>, Sergii Golovatiuk
>     <sgolovatiuk@xxxxxxxxxxxx <mailto:sgolovatiuk@xxxxxxxxxxxx>>
> 
>     Subject: Re: [Fuel-dev] overcommit rates
> 
>     David,
> 
>     1. Yes
>     2. Yes, same as other Settings which Fuel can "re-apply" today
>     (syslog server, scheduler type, etc). As Sergey pointed out, there's
>     no danger in it, and there should not be any additional technical
>     effort to implement. The only thing is - we need to add a note on UI
>     and/or in documentation to explain to user that changing overcommit
>     rate to lower will not automatically offload Compute nodes that are
>     already over-provisioned, he/she will still need to migrate
>     excessive VMs away:)
>     3. No, no monitoring. Fuel master should be the only source of
>     "truth" for those settings which are exposed to user on Web UI.
> 
> 
>     ---
>     Regards,
>     Dmitriy
> 
> 
>     On Tue, Jun 24, 2014 at 8:35 PM, Sergii Golovatiuk
>     <sgolovatiuk@xxxxxxxxxxxx <mailto:sgolovatiuk@xxxxxxxxxxxx>> wrote:
> 
>         Hi,
> 
>         IMHO,
> 
>         1. Yes
>         2. In theory, it's possible to change/update values after
>         deployment time. It's not a dangerous operation. If node is
>         full, it won't be selected for new VM starts.
>         3. If it's changed manually, it will be reset on next puppet run.
> 
>         ~Sergii
> 
> 
>         On Tue, Jun 24, 2014 at 5:21 PM, David Easter
>         <deaster@xxxxxxxxxxxx <mailto:deaster@xxxxxxxxxxxx>> wrote:
> 
>             Dmitriy,
> 
>               Once set through the UI, I have a few questions on
>             expectations post-deployment:
> 
>              1. Would the value selected need to be shown within the
>                 Fuel UI post-deployment to let the administrator know
>                 what value was selected per environment?
>              2. Is there an expectation that the value can be changed in
>                 a running environment, or would this only be expected at
>                 deployment time?
>              3. If the value were changed in the environment manually,
>                 would be expected that the Fuel Master Node would need
>                 to monitor for such changes?
> 
>             Thanks,
> 
>             - David J. Easter
>               Director of Product Management, Mirantis
> 
>             From: Dmitriy Novakovskiy <dnovakovskiy@xxxxxxxxxxxx
>             <mailto:dnovakovskiy@xxxxxxxxxxxx>>
>             Date: Tuesday, June 24, 2014 at 4:37 AM
>             To: Bogdan Dobrelya <bdobrelia@xxxxxxxxxxxx
>             <mailto:bdobrelia@xxxxxxxxxxxx>>
>             Cc: fuel-dev <fuel-dev@xxxxxxxxxxxxxxxxxxx
>             <mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>>
>             Subject: Re: [Fuel-dev] overcommit rates
> 
>             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 <mailto: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>
>                 > <mailto: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>
>                 >     <mailto: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>
>                 <mailto:jesse.pretorius@xxxxxxxxx
>                 <mailto:jesse.pretorius@xxxxxxxxx>>>
>                 >         wrote:
>                 >
>                 >             On 23 June 2014 23:02, Dmitry Borodaenko
>                 >             <dborodaenko@xxxxxxxxxxxx
>                 <mailto:dborodaenko@xxxxxxxxxxxx>
>                 <mailto: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>
>                 >             <mailto: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>
>                 >         <mailto: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>
>                 >     <mailto: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 <http://bogdando_at_yahoo.com>
>                 Irc #bogdando
> 
> 
>             -- 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