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