← Back to team overview

fuel-dev team mailing list archive

Re: overcommit rates

 

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

Follow ups

References