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 <ogelb...@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 <mmoses...@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 <ikalnit...@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 >> > <mmoses...@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 >> >> <vkozhuka...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
