fuel-dev team mailing list archive

[David Easter <deaster@xxxxxxxxxxxx>]

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>
Date:  Tuesday, June 24, 2014 at 11:54 AM
To:  David Easter <deaster@xxxxxxxxxxxx>
Cc:  Bogdan Dobrelya <bdobrelia@xxxxxxxxxxxx>, fuel-dev
<fuel-dev@xxxxxxxxxxxxxxxxxxx>, Sergii Golovatiuk <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> 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> 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>
>> Date:  Tuesday, June 24, 2014 at 4:37 AM
>> To:  Bogdan Dobrelya <bdobrelia@xxxxxxxxxxxx>
>> Cc:  fuel-dev <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>
>> 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 <http://bogdando_at_yahoo.com>
>>> Irc #bogdando
>> 
>> -- 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
>> 
>> --
>> 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
>> 
>