fuel-dev team mailing list archive

[Dmitriy Novakovskiy <dnovakovskiy@xxxxxxxxxxxx>]

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
>>> 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
>>
>>
>