Open Stack

Mike,

It's great that we are continuing to align fuel with TripleO. I've been
toying with the idea of using TripleO components and CEPH to enhance our CI
infra for a while now, and this announcement has encouraged me to write it
down. I've proposed a BP for "Super fast deploy CI" that would help us
perform CI better by "accelerate fuel CI testing by taking reasonable
shortcuts integrating with several existing components like TripleO and
CEPH".

Blueprint:
https://blueprints.launchpad.net/fuel/+spec/fuel-superfastdeploy-ci
Pad Spec: https://etherpad.openstack.org/p/bp-fuel-superfastdeploy-ci

--
Andrew Woodward
Mirantis


On Thu, Dec 12, 2013 at 6:31 AM, Mike Scherbakov
<mscherbakov at mirantis.com>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/fueland
> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20131212/fe51a7ea/attachment.html>