Open Stack

Oleg, those parameters are no longer documented (because there was no
validation) and are absent from the Fuel User Guide. They are,
however, still used by fuel-qa scripts.

On Thu, Jul 23, 2015 at 5:26 PM, Oleg Gelbukh <ogelbukh at mirantis.com> wrote:
> Unless I am mistaken, it is possible to set most of the parameters supported
> by Fuel menu as kernel boot parameters. Isn't it sufficient replacement for
> fuelmenu for dev's purposes?
>
> -Oleg
>
> On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn <mmosesohn at mirantis.com>
> wrote:
>>
>> How much effort are we spending? I'm not so sure it's a major development
>> drain.
>>
>> Since Fuel 6.0 dev cycle (Sept 2014) until now there have been 34
>> commits into Fuelmenu:
>> * New features/functionality: 12
>> * Bugfix: 15
>> * Other: 7 (version bumps, and commits without bug ID)
>>
>> Across 3 releases, that's only ~11 commits per release. We've added
>> features like generating random passwords for services, warnings about
>> setting credentials apart from the default, adding a hook for CI for
>> testing custom manifests on Fuel Master, and duplicate IP address
>> checks.
>>
>> These improved user experience. If you take it away and replace it
>> with a config file with basic validation, we will see users fail to
>> deploy due to things that Fuelmenu already checks easily. Imagine
>> you're an existing user of Fuel and suddenly you install the newest
>> version of Fuel and see a large configuration file which you have to
>> set by hand. Here's a relic of what users used to have to configure by
>> hand:
>>
>> https://github.com/stackforge/fuel-library/blob/b015ed975b58dddff3b8da0ce34d9a638c22d032/deployment/puppet/openstack/examples/site_simple.pp
>>
>> 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?
>>
>> On Thu, Jul 23, 2015 at 3:33 PM, Igor Kalnitsky <ikalnitsky at mirantis.com>
>> wrote:
>> > Hello,
>> >
>> > Here's my 2 cents on it.
>> >
>> > I think the effort we put to support fuelmenu doesn't worth it. I used
>> > to deploy fuel too often in previous release, and I never used
>> > features of fuelmenu? Why? Because I prefer to apply changes on
>> > already deployed node. Moreover, I don't like that users are prompted
>> > with fuelmenu by default. I want to deploy fuel automatically, without
>> > any manual actions (though it's another topic).
>> >
>> > I'm agree with Vladimir, vim + config files are enough, since Fuel is
>> > not a product for housewives. It's a product for those who do not
>> > hesitate to use Vim for soft configuration.
>> >
>> > Thanks,
>> > Igor
>> >
>> >
>> >
>> > On Thu, Jul 23, 2015 at 2:27 PM, Matthew Mosesohn
>> > <mmosesohn at mirantis.com> wrote:
>> >> We had that before and had very poor validation. Removing fuelmenu
>> >> would make the experience quite manual and prone to errors.
>> >>
>> >> This topic comes up once a year only from Fuel Python developers
>> >> because they rarely use it and no dev cycles have been invested in
>> >> improving it.
>> >>
>> >> The actual Fuel deployers use it and appreciate its validation and
>> >> wish to extend it.
>> >>
>> >> I'd like to hear more feedback.
>> >>
>> >> On Thu, Jul 23, 2015 at 2:23 PM, Vladimir Kozhukalov
>> >> <vkozhukalov at mirantis.com> wrote:
>> >>> Dear colleagues,
>> >>>
>> >>> What do you think of getting rid of fuelmenu and substituting it with
>> >>> thoroughly commented text file + some validation + vim? The major pro
>> >>> of
>> >>> this is that text file is easier to extend and edit. Many people
>> >>> prefer vim
>> >>> UX instead of wandering through the semi-graphical interface. And it
>> >>> is not
>> >>> so hard to implement syntax and logic checking for the text file.
>> >>>
>> >>> Please give your opinions about this.
>> >>>
>> >>> Vladimir Kozhukalov
>> >>>
>> >>>
>> >>> __________________________________________________________________________
>> >>> OpenStack Development Mailing List (not for usage questions)
>> >>> Unsubscribe:
>> >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>
>> >>
>> >>
>> >> __________________________________________________________________________
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> > __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>