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
