Open Stack

Oleg,

Thanks a lot for your opinion. Here are some more thoughts on this topic.

1) For a package it is absolutely normal to throw a user dialog. But
probably there is kind of standard for the dialog that does not allow to
use fuelmenu. AFAIK, for DEB packages it is debconf and there is a tutorial
[0] how to get user input during post install. I don't know if there is
such a standard for RPM packages. In some MLs it is written that any
command line program could be run in %post section including those like
fuel-menu.

2) Fuel package could install default astute.yaml (I'd like to rename it
into /etc/fuel.yaml or /etc/fuel/config.yaml) and use values from the file
by default not running fuelmenu. A user then is supposed to run fuelmenu if
he/she needs to re-configure fuel installation. However, it is gonna be
quite intrusive. What if a user installs fuel and uses it for a while with
default configuration. What if some clusters are already in use and then
the user decides to re-configure the master node. Will it be ok?

3) What is wrong with 'deployment script' approach? Why can not fuel just
install kind of deployment script? Fuel is not a service, it consists of
many components. Moreover some of these components could be optional (not
currently but who knows?), some of this components could be run on an
external node (after all Fuel components use REST, AMQP, XMLRPC to interact
with each other).
Imagine you want to install OpenStack. It also consists of many components.
Some components like database or AMQP service could be deployed using HA
architecture. What if one needs Fuel to be run with external HA database,
amqp? From this perspective I'd say Fuel package should not exist at all.
Let's maybe think of Fuel package as a convenient way to deploy Fuel on a
single node, i.e single node deployment script.

4) If Fuel is just a deployment script, then I'd say we should not run any
post install dialog. Deployment script is to run this dialog (fuelmenu) and
then run puppet. IMO it sounds reasonable.


[0] http://www.fifi.org/doc/debconf-doc/tutorial.html

Vladimir Kozhukalov

On Fri, Dec 11, 2015 at 11:14 PM, Oleg Gelbukh <ogelbukh at mirantis.com>
wrote:

> For the package-based deployment, we need to get rid of 'deployment
> script' whatsoever. All configuration stuff should be done in package
> specs, or by the user later on (maybe via some fuelmenu-like lightweight
> UI, or via WebUI).
>
> Thus, fuel package must install everything that is required for running
> base Fuel as it's dependencies (or dependencies of it's dependencies, as it
> could be more complicated with cross-deps between our components).
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Fri, Dec 11, 2015 at 10:45 PM, Vladimir Kozhukalov <
> vkozhukalov at mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> At the moment part of the Fuel master deployment logic is located in ISO
>> kickstart file, which is bad. We'd better carefully split provisioning and
>> deployment stages so as to install base operating system during
>> provisioning stage and then everything else on the deployment stage. That
>> would make it possible to deploy Fuel on pre-installed vanilla Centos 7.
>> Besides, if we have deb packages for all Fuel components it will be easy to
>> support Fuel deployment on pre-installed Ubuntu and Debian.
>>
>> We (Fuel build team) are going to do this ASAP [0]. Right now we are on
>> the stage of writing design spec for the change [1].
>>
>> Open questions are:
>> 1) Should fuel package have all other fuel packages like nailgun, astute,
>> etc. as its dependencies? Or maybe it should install only puppet modules
>> and deployment script that then could be used to deploy everything else?
>>
>> 2) bootstrap_admin_node.sh runs fuelmenu and then puppet to deploy Fuel
>> components. Should we run this script as post-install script or maybe we
>> should leave this up to a user to run this script later when fuel package
>> is already installed?
>>
>> Anyway, the final goal is to make ISO just one of possible delivery
>> schemes. Primary delivery approach should be rpm/deb repo, not ISO.
>>
>> [0]
>> https://blueprints.launchpad.net/fuel/+spec/separate-fuel-node-provisioning
>> [1] https://review.openstack.org/#/c/254270/
>>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151214/ce3e490b/attachment-0001.html>