fuel-dev team mailing list archive
-
fuel-dev team
-
Mailing list archive
-
Message #00161
Re: [openstack-dev] Announcing Fuel
Hi Mike,
On Thu, 2013-12-12 at 18:31 +0400, Mike Scherbakov wrote:
> Folks,
>
> Most of you by now have heard of Fuel, which we’ve been working on as a
> related OpenStack project for a period of time -
> <https://github.com/stackforge/fuel-main>see https://launchpad.net/fuel and
> https://wiki.openstack.org/wiki/Fuel. The aim of the project is to provide
> a distribution agnostic and plug-in agnostic engine for preparing,
> configuring and ultimately deploying various “flavors” of OpenStack in
> production. We’ve also used Fuel in most of our customer engagements to
> stand up an OpenStack cloud.
>
> At the same time, we’ve been actively involved with TripleO, which we
> believe to be a great effort in simplifying deployment, operations, scaling
> (and eventually upgrading) of OpenStack.
>
> Per our discussions with core TripleO team during the Icehouse summit,
> we’ve uncovered that while there are certain areas of collision, most of
> the functionality in TripleO and Fuel is complementary. In general, Fuel
> helps solve many problems around “step zero” of setting up an OpenStack
> environment, such as auto-discovery and inventory of bare metal hardware,
> pre-deployment & post-deployment environment checks, and wizard-driven
> web-based configuration of OpenStack flavors. At the same time, TripleO has
> made great progress in deployment, scaling and operations (with Tuskar).
>
> We’d like to propose an effort for community consideration to bring the two
> initiatives closer together to eventually arrive at a distribution
> agnostic, community supported framework covering the entire spectrum of
> deployment, management and upgrades; from “step zero” to a fully functional
> and manageable production-grade OpenStack environment.
Great!
> To that effect, we propose the following high-level roadmap plans for this
> effort:
>
>
> -
>
> Keep and continue to evolve bare-metal discovery and inventory module of
> Fuel, tightly integrating it with Ironic.
> -
>
> Keep and continue to evolve Fuel’s wizard-driven OpenStack flavor
> configurator. In the near term we’ll work with the UX team to unify the
> user experience across Fuel, TripleO and Tuskar. We are also thinking about
> leveraging diskimagebuilder.
> -
>
> Continue to evolve Fuel’s pre-deployment (DHCP, L2 connectivity checks)
> and post-deployment validation checks in collaboration with the TripleO and
> Tempest teams.
> -
>
> Eventually replace Fuel’s current orchestration engine
> https://github.com/stackforge/fuel-astute/ with Heat
This all sounds great to me.
I'd especially like to see some more in-depth discussion about how your
ideas for a configuration wizard like this:
http://software.mirantis.com/wp-content/uploads/2013/10/New_Fuel_3.2_Wizard_1-of-3.png
http://software.mirantis.com/wp-content/uploads/2013/10/New_Fuel_3.2_Wizard_3-of-3.png
fits into the UX discussions around initial deployment with TripleO
going on, for example:
http://ask-openstackux.rhcloud.com/question/96/tripleo-ui-deployment-management/
http://lists.openstack.org/pipermail/openstack-dev/2013-December/thread.html#21388
http://lists.openstack.org/pipermail/openstack-dev/2013-December/thread.html#20944
Thanks!
Mark.
References