Fuel

What is Fuel?

Fuel is an all-in-one control plane for automated hardware discovery, network verification, operating systems provisioning and deployment of OpenStack. It provides user-friendly Web interface for installations management, simplifying OpenStack installation up to a few clicks.

This installer has been battle-tested during 2013 in a number of OpenStack deployments on platforms like as Dell (C6220 & R320), HP (DL380), Supermicro (6027TR-HTRF), Lenovo ThinkServer (RD530) and Cisco UCS-C.

The key features are:

• hardware discovery
• hardware configuration in UI (networks & disk partitioning)
• ability to spin up and manage multiple OpenStack clusters
• support for non-HA and HA OpenStack deployment configurations
• pre-deployment checks and network validation
• post-deployment checks and running a set of tests for validating deployed OpenStack
• view logs in real-time through UI
• support for CentOS, Ubuntu, and RHEL
• support for multiple OpenStack distributions

Fuel architecture

Fuel is not monolithic. It consists of several independent components. Some of those components are Fuel specific components, while others are third-party services like Cobbler, Puppet, Mcollective, etc.

• The heart of Fuel project is it's engine service Nailgun. Nailgun as other Openstack projects is written in Python programming language. It implements REST API as well as deployment data mangement. It manage disk volumes configuration data, networks configuration data and any other environment specific data which are necessary for successful deployment. Nailgun uses SQL database to store its data and AMQP service to interact with orchestration component.
• Another extremely important component is so called orchestrator. It is written in Ruby and we tried it to be as much data driven as possible. In fact, the orchestrator is nothing more than just a layer which encapsulates all the details about interaction with a variety of services such as Cobbler, Puppet, shell scripts, etc. and provides universal asynchronous interface to those services. Depending on what we need to do we can either manage service directly via its native protocol (for example XML-RPC protocol is used for Cobbler) or we can Mcollective agents to perform specific tasks such as launching "puppet apply" on a remote node or running some shell script.

Development

Development Documentation

IRC: #fuel, #fuel-dev on freenode.net

Source code

Build system

REST API service, UI

Openstack Healthcheck

Deployment Orchestrator

Puppet modules and manifests

User Documentation

Pending Code Reviews

https://review.openstack.org/#q,status:open+fuel,n,z

Project space

https://launchpad.net/fuel

Blueprints

https://blueprints.launchpad.net/fuel

Bugs

https://bugs.launchpad.net/fuel

Roadmap

Version 4.1

• Patching / Upgrade of Fuel
  • Retain knowledge / manageability of previously deployed environments
  • Automate patching of the Fuel Master Node
• Patching of OpenStack
  • Automate patching of previously deployed OpenStack services / drivers - core and vendor added
• Pluggable Architecture
  • Ability to add additional modules of functionality to Fuel either in distro or post-install
  • Activate options in UI only when packages are present on Fuel master node

Version 5.0

• Support for deploying and managing OpenStack IceHouse
• Upgrading OpenStack
  • Automate upgrading from one major OpenStack version to a later version (e.g. Havana to IceHouse)
  • Strive to minimize accessibility downtime

Web-site

http://software.mirantis.com/