fuel-dev team mailing list archive

[Dmitriy Novakovskiy <dnovakovskiy@xxxxxxxxxxxx>]

Ok. Should I do it? I can specify UI/Use Case suggestion, assuming that
someone in the team will pick it up and provide implementation approach

---
Regards,
Dmitriy


On Tue, Jun 24, 2014 at 2:05 PM, Sergii Golovatiuk <sgolovatiuk@xxxxxxxxxxxx
> wrote:

> Hi,
>
> Let's create a blueprint. We may enhance UI and toss those values to
> astute.xml.
>
> ~Sergii
>
>
>
> On Tue, Jun 24, 2014 at 1:50 PM, Dmitriy Novakovskiy <
> dnovakovskiy@xxxxxxxxxxxx> 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
>>
>>
>> ---
>> Regards,
>> Dmitriy
>>
>>
>> On Tue, Jun 24, 2014 at 1:23 PM, Andrey Danin <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>
>>> 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> wrote:
>>>>
>>>>> On 23 June 2014 23:02, Dmitry Borodaenko <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
>>>>> 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
>>>>
>>>>
>>> --
>>> 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
>>
>>
>