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 <[email protected] > 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 < > [email protected]> 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 <[email protected]> >> 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" <[email protected]> >>> 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 < >>>> [email protected]> wrote: >>>> >>>>> On 23 June 2014 23:02, Dmitry Borodaenko <[email protected]> >>>>> 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 : [email protected] >>>>> Unsubscribe : https://launchpad.net/~fuel-dev >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>> >>>> -- >>>> Mailing list: https://launchpad.net/~fuel-dev >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~fuel-dev >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>> -- >>> Mailing list: https://launchpad.net/~fuel-dev >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~fuel-dev >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> >> -- >> Mailing list: https://launchpad.net/~fuel-dev >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~fuel-dev >> More help : https://help.launchpad.net/ListHelp >> >> >
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
