<div dir="ltr"><div><div>> Meantime we can provide fuel-menu which will become a configuration</div><div>> gate for different subprojects. Perhaps we could consider to use</div><div>> pluggable approach, so each component will export plugin for fuel-menu</div><div>> with own settings.</div></div><div><br></div><div>fuel-menu could be a configuration gate for fuel deployment script</div><div><br></div><div><div>> The wrong thing is that with such approach it would be impossible to</div><div>> setup Fuel with just something like</div><div><br></div><div>>    $ yum install fuel</div></div><div><br></div><div>I see nothing wrong here. 'yum install fuel' would be appropriate approach if fuel was a service, </div><div>not a bunch of services some of which are not even limited to be installed on the master node.  </div><div><br></div><div>when you run</div><div><br></div><div># yum install fuel</div><div># fuel-menu</div><div><br></div><div>it the same as you run </div><div><br></div><div># yum install fuel</div><div># fuel_deploy_script (which runs fuel-menu and then runs puppet which installs everything else)</div><div><br></div><div>I like the idea when fuel (let's rename it into fuel-deploy) package provides just a deployment script. </div><div>It does not require a lot of changes and it corresponds to what we really do. Besides, it is more flexible</div><div>because deployment could be modular (several stages).</div><div><br></div><div>One of potential disadvantages is that it is harder to track package dependencies, but I think </div><div>a deployment script should be a root of the package dependency tree.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div>Vladimir Kozhukalov</div></div></div>
<br><div class="gmail_quote">On Mon, Dec 14, 2015 at 12:53 PM, Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Vladimir,<br>
<br>
Thanks for raising this question. I totally support idea of separating<br>
provisioning and deployment steps. I believe it'll simplify a lot of<br>
things.<br>
<br>
However I have some comments regarding this topic, see them inline. :)<br>
<span class=""><br>
> For a package it is absolutely normal to throw a user dialog.<br>
<br>
</span>It kills idea of fuel-menu, since each package will need to implement<br>
configuration menu of its own. Moreover, having such configuration<br>
menu in fuel-menu and in each package is too expensive, it will<br>
require more effort that I'd like to have.<br>
<span class=""><br>
> Fuel package could install default astute.yaml (I'd like to rename it<br>
> into /etc/fuel.yaml or /etc/fuel/config.yaml) and use values from the<br>
> file by default not running fuelmenu<br>
<br>
</span>I don't like idea of having one common configuration file for Fuel<br>
components. I think it'd be better when each component (subproject)<br>
has its own configuration file, and knows nothing about external ones.<br>
<br>
Meantime we can provide fuel-menu which will become a configuration<br>
gate for different subprojects. Perhaps we could consider to use<br>
pluggable approach, so each component will export plugin for fuel-menu<br>
with own settings.<br>
<span class=""><br>
> What is wrong with 'deployment script' approach?<br>
<br>
</span>The wrong thing is that with such approach it would be impossible to<br>
setup Fuel with just something like<br>
<br>
    $ yum install fuel<br>
<br>
In my opinion we should go into the following approach:<br>
<br>
* yum install fuel<br>
* fuel-menu<br>
<br>
The first command should install a basic Fuel setup, and everything<br>
should work when it's done.<br>
<br>
While the second one prompts a configuration menu where one might<br>
change default settings (reconfigure default installation).<br>
<br>
Thanks,<br>
Igor<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Dec 14, 2015 at 9:30 AM, Vladimir Kozhukalov<br>
<<a href="mailto:vkozhukalov@mirantis.com">vkozhukalov@mirantis.com</a>> wrote:<br>
> Oleg,<br>
><br>
> Thanks a lot for your opinion. Here are some more thoughts on this topic.<br>
><br>
> 1) For a package it is absolutely normal to throw a user dialog. But<br>
> probably there is kind of standard for the dialog that does not allow to use<br>
> fuelmenu. AFAIK, for DEB packages it is debconf and there is a tutorial [0]<br>
> how to get user input during post install. I don't know if there is such a<br>
> standard for RPM packages. In some MLs it is written that any command line<br>
> program could be run in %post section including those like fuel-menu.<br>
><br>
> 2) Fuel package could install default astute.yaml (I'd like to rename it<br>
> into /etc/fuel.yaml or /etc/fuel/config.yaml) and use values from the file<br>
> by default not running fuelmenu. A user then is supposed to run fuelmenu if<br>
> he/she needs to re-configure fuel installation. However, it is gonna be<br>
> quite intrusive. What if a user installs fuel and uses it for a while with<br>
> default configuration. What if some clusters are already in use and then the<br>
> user decides to re-configure the master node. Will it be ok?<br>
><br>
> 3) What is wrong with 'deployment script' approach? Why can not fuel just<br>
> install kind of deployment script? Fuel is not a service, it consists of<br>
> many components. Moreover some of these components could be optional (not<br>
> currently but who knows?), some of this components could be run on an<br>
> external node (after all Fuel components use REST, AMQP, XMLRPC to interact<br>
> with each other).<br>
> Imagine you want to install OpenStack. It also consists of many components.<br>
> Some components like database or AMQP service could be deployed using HA<br>
> architecture. What if one needs Fuel to be run with external HA database,<br>
> amqp? From this perspective I'd say Fuel package should not exist at all.<br>
> Let's maybe think of Fuel package as a convenient way to deploy Fuel on a<br>
> single node, i.e single node deployment script.<br>
><br>
> 4) If Fuel is just a deployment script, then I'd say we should not run any<br>
> post install dialog. Deployment script is to run this dialog (fuelmenu) and<br>
> then run puppet. IMO it sounds reasonable.<br>
><br>
><br>
> [0] <a href="http://www.fifi.org/doc/debconf-doc/tutorial.html" rel="noreferrer" target="_blank">http://www.fifi.org/doc/debconf-doc/tutorial.html</a><br>
><br>
> Vladimir Kozhukalov<br>
><br>
> On Fri, Dec 11, 2015 at 11:14 PM, Oleg Gelbukh <<a href="mailto:ogelbukh@mirantis.com">ogelbukh@mirantis.com</a>><br>
> wrote:<br>
>><br>
>> For the package-based deployment, we need to get rid of 'deployment<br>
>> script' whatsoever. All configuration stuff should be done in package specs,<br>
>> or by the user later on (maybe via some fuelmenu-like lightweight UI, or via<br>
>> WebUI).<br>
>><br>
>> Thus, fuel package must install everything that is required for running<br>
>> base Fuel as it's dependencies (or dependencies of it's dependencies, as it<br>
>> could be more complicated with cross-deps between our components).<br>
>><br>
>> --<br>
>> Best regards,<br>
>> Oleg Gelbukh<br>
>><br>
>> On Fri, Dec 11, 2015 at 10:45 PM, Vladimir Kozhukalov<br>
>> <<a href="mailto:vkozhukalov@mirantis.com">vkozhukalov@mirantis.com</a>> wrote:<br>
>>><br>
>>> Dear colleagues,<br>
>>><br>
>>> At the moment part of the Fuel master deployment logic is located in ISO<br>
>>> kickstart file, which is bad. We'd better carefully split provisioning and<br>
>>> deployment stages so as to install base operating system during provisioning<br>
>>> stage and then everything else on the deployment stage. That would make it<br>
>>> possible to deploy Fuel on pre-installed vanilla Centos 7. Besides, if we<br>
>>> have deb packages for all Fuel components it will be easy to support Fuel<br>
>>> deployment on pre-installed Ubuntu and Debian.<br>
>>><br>
>>> We (Fuel build team) are going to do this ASAP [0]. Right now we are on<br>
>>> the stage of writing design spec for the change [1].<br>
>>><br>
>>> Open questions are:<br>
>>> 1) Should fuel package have all other fuel packages like nailgun, astute,<br>
>>> etc. as its dependencies? Or maybe it should install only puppet modules and<br>
>>> deployment script that then could be used to deploy everything else?<br>
>>><br>
>>> 2) bootstrap_admin_node.sh runs fuelmenu and then puppet to deploy Fuel<br>
>>> components. Should we run this script as post-install script or maybe we<br>
>>> should leave this up to a user to run this script later when fuel package is<br>
>>> already installed?<br>
>>><br>
>>> Anyway, the final goal is to make ISO just one of possible delivery<br>
>>> schemes. Primary delivery approach should be rpm/deb repo, not ISO.<br>
>>><br>
>>> [0]<br>
>>> <a href="https://blueprints.launchpad.net/fuel/+spec/separate-fuel-node-provisioning" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/fuel/+spec/separate-fuel-node-provisioning</a><br>
>>> [1] <a href="https://review.openstack.org/#/c/254270/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/254270/</a><br>
>>><br>
>>> Vladimir Kozhukalov<br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <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>
>><br>
>><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>
><br>
><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>
<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>
</div></div></blockquote></div><br></div>