Open Stack

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.

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


We’d love to open discussion on this and hear everybody’s thoughts on this
direction.

-- 
Mike Scherbakov
Fuel Engineering Lead
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131212/8abae040/attachment.html>