<div dir="ltr">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).<div><br></div><div>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).</div><div><br></div><div>--</div><div>Best regards,</div><div>Oleg Gelbukh</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 11, 2015 at 10:45 PM, Vladimir Kozhukalov <span dir="ltr"><<a href="mailto:vkozhukalov@mirantis.com" target="_blank">vkozhukalov@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"><div>Dear colleagues,</div><div><br></div><div>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.</div><div><br></div><div>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].</div><div><br></div><div>Open questions are:</div><div>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? </div><div><br></div><div>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?</div><div><br></div><div>Anyway, the final goal is to make ISO just one of possible delivery schemes. Primary delivery approach should be rpm/deb repo, not ISO.<br></div><div><br></div><div>[0] <a href="https://blueprints.launchpad.net/fuel/+spec/separate-fuel-node-provisioning" target="_blank">https://blueprints.launchpad.net/fuel/+spec/separate-fuel-node-provisioning</a><br></div><div>[1] <a href="https://review.openstack.org/#/c/254270/" target="_blank">https://review.openstack.org/#/c/254270/</a></div><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div><div>Vladimir Kozhukalov</div></div></div>
</font></span></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>