fuel-dev team mailing list archive

[Sergii Golovatiuk <sgolovatiuk@xxxxxxxxxxxx>]

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