[openstack-dev] [Fuel] Get rid of fuelmenu
aschultz at mirantis.com
Thu Jul 23 17:04:03 UTC 2015
For this to be consumable by end-users, a config file and editor (vim
seriously?) is terrible UX. We need to remember who we are targeting to
consume this functionality as it may not be an expert or even someone
absolutely familiar with the linux tool set. While the existing thing may
be awkward, it is going to be less error prone to someone accidentally
deleteing half of a config file and not being able to recover. If you want
to ditch ncurses, then sure why don't we switch to an answer file and
question/answer wizard for configuration? This would allow both validation
and the ability to override it with a config file.
On Thu, Jul 23, 2015 at 11:49 AM, Vladimir Kozhukalov <
vkozhukalov at mirantis.com> wrote:
> The topic is NOT 'get rid of validation' but rather 'get rid of
> semi-graphical ncurses based interface'. It is not so hard to adopt every
> piece of validation we currently have in fuelmenu and implement even more
> including syntax validation using, for example, PLY and logic validation.
> My idea is to switch from ncurses to plain text file (thoroughly
> commented), because it so easy to add new parameters or remove those we
> don't need any more.
> Vladimir Kozhukalov
> On Thu, Jul 23, 2015 at 6:17 PM, Nick Chase <nchase at mirantis.com> wrote:
>> On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn <
>> <mmosesohn at mirantis.com>mmosesohn at mirantis.com> wrote:
>>> Here's a relic of what users used to have to configure by
>>> Am I alone in thinking it's not the best use of our development
>>> resources to throw it away and replace it with a text file that is
>>> edited by hand?
>> Please, please, please, I'm having PTSD just remembering that @#$%@#%$
>> file. I think I was able to successfully deploy without major engineering
>> help about 2% of the time. We absolutely, positively, MUST maintain the
>> Just because the people installing OpenStack are generally not afraid to
>> edit config files doesn't mean that we should be making them do it.
>> ---- Nick
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev