Dear colleagues,
The spec for this feature is ready for review [0], so I'd like to encourage
all the parties concerned in Fuel modularization to participate.
Thanks
[0] https://review.openstack.org/#/c/254270/
On Fri, Dec 11, 2015 at 9:45 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wro
> One of potential disadvantages is that it is harder to track package
> dependencies, but I think
> a deployment script should be a root of the package dependency tree.
That's something I'd try to avoid. Let's be close to distro upstream
practice. I never saw something like "fuel-deploy" that ru
> Meantime we can provide fuel-menu which will become a configuration
> gate for different subprojects. Perhaps we could consider to use
> pluggable approach, so each component will export plugin for fuel-menu
> with own settings.
fuel-menu could be a configuration gate for fuel deployment script
Vladimir,
Thanks for raising this question. I totally support idea of separating
provisioning and deployment steps. I believe it'll simplify a lot of
things.
However I have some comments regarding this topic, see them inline. :)
> For a package it is absolutely normal to throw a user dialog.
It
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
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 runn
