Flexible and easy to use operating system installation tool.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
OpenDev Sysadmins d29fb70147 OpenDev Migration Patch 1 month ago
bareon Improve validation error message 1 year ago
cloud-init-templates Run console on the serial port if required 2 years ago
contrib Remove log translations 2 years ago
doc Do not use “-y” for package install 1 year ago
etc Get root password for build image from settings 2 years ago
.gitignore Add functional tests to Bareon 2 years ago
.gitreview OpenDev Migration Patch 1 month ago
LICENSE Add README.md and LICENSE 3 years ago
MANIFEST.in Add doc, etc and cloud-init-templates directories to python egg 3 years ago
README.md Add functional tests to Bareon 2 years ago
requirements.txt Satisfy global dependencies requirements for master branch 2 years ago
run_tests.sh Added infrastructure files 3 years ago
setup.cfg Merge "Register all config options in one place" 2 years ago
setup.py Update from global requirements 3 years ago
test-requirements.txt Satisfy global dependencies requirements for master branch 2 years ago
tox.ini Fix OpenStack dependencies 1 year ago



Table of Contents


Bareon is nothing more than just a set of data driven executable scripts.

  • One of these scripts is used for building operating system images. One can run this script on wherever needed passing a set of repository URIs and a set of package names that are to be installed into the image.
  • Another script is used for the actual provisioning. This script being installed into a ramdisk (live image) can be run to provision an operating system on a hard drive. When running one needs to pass input data that contain information about disk partitions, initial node configuration, operating system image location, etc. This script is to prepare disk partitions according to the input data, download operating system images and put these images on partitions.


  • Native operating installation tools like anaconda and debian-installer are:
    • hard to customize (if the case is really non-trivial)
    • hard to troubleshoot (it is usually quite difficult to understand which log file contains necessary information and how to run those tools in debug mode)
  • Image based approach to operating system installation allows to make this process really scalable. For example, we can use BitTorrent based image delivery scheme when provisioning that makes the process easily scalable up to thousands of nodes.
  • When provisioning we can check hash sum of the image and use other validation mechanisms that can make the process more stable.

Designed to address requirements

  • Support various input data formats (pluggable input data drivers)
  • Support plain partitions, lvm, md, root on lvm, etc.
  • Be able to do initial node configuration (network, mcollective, puppet, ntp)
  • Be able to deploy standalone OS (local kernel, local bootloader)
  • Support various image storages (tftp, http, torrent)
  • Support various image formats (compressed, disk image, fs image, tar image)

Design outline

  • Use cloud-init for initial node configuration
  • Avoid using parted and lvm native python bindings (to make it easy to troubleshoot and modify for deployment engineers)
  • No REST API, just executable entry points (like /usr/bin/fa_*)
  • Passing input data either via file (--input_data_file) or CLI parameter (--input_data)
  • Detailed logging of all components


Basic Repository Layout

├── cloud-init-templates
├── contrib
├── debian
├── etc
├── bareon
│   ├── cmd
│   ├── drivers
│   ├── objects
│   ├── tests
│   ├── tests_functional
│   ├── utils
├── README.md
├── requirements.txt
├── run_tests.sh
├── setup.cfg
├── setup.py
├── specs
├── test-requirements.txt


The root level contains important repository documentation and license information. It also contais files which are typical for the infracture of python project such as requirements.txt and setup.py


This folder contains Jinja2 templates to prepare cloud-init related data for nocloud datasource.


This directory contains third party code that is not a part of bareon itself but can be used together with bareon.


This folder contains the DEB package specification. Included debian rules are mainly suitable for Ubuntu 12.04 or higher.


This folder contains the sample config file for bareon. Every parameter is well documented. We use oslo-config as a configuration module.


This folder contains the python code: drivers, objects, unit tests and utils, manager and entry points.

  • bareon/cmd/agent.py
    • That is where executable entry points are. It reads input data and instantiates DeployDriver class with these data.
  • bareon/manager.py
    • That is the file where the top level agent logic is implemented. It contains all those methods which do something useful (do_*)
  • bareon/drivers
    • That is where input data drivers are located. (Nailgun, NailgunBuildImage, Simple etc.) Data drivers convert json into a set of python objects.
  • bareon/objects
    • Here is the place where python objects are defined. Bareon manager does not understand any particular data format except these objects. For example, to do disk partitioning we need PartitionScheme object. PartitionScheme object in turn contains disk labels, plain partitions, lvm, md, fs objects. This PartitionScheme object is to be created by input data driver.
  • bareon/utils
    • That is the place where we put the code which does something useful on the OS level. Here we have simple parted, lvm, md, grub bindings, etc.


This folder contains the RPM package specfication file. Included RPM spec is mainly suitable for Centos 6.x or higher.


Use case #1 (Fuel)

Bareon is used in Fuel project as a part of operating system provisioning scheme. When a user starts deployment of OpenStack cluster, the first task is to install an operating system on slave nodes. First, Fuel runs bareon on the master node to build OS images. Once images are built, Fuel then runs bareon on slave nodes using Mcollective. Slave nodes are supposed to be booted with so called bootstrap ramdisk. Bootstrap ramdisk is an in-memory OS where bareon is installed.

Detailed documentation on this case is available here:

Use case #2 (Independent on Fuel)

Bareon can easily be used in third party projects as a convenient operating system provisioning tool. As described above bareon is fully data driven and supports various input data formats using pluggable input data drivers. Currently there are three input data drivers available. Those are

  • NailgunBuildImage and Nailgun
    • Build image and provisioning input data drivers used in Fuel project. To use them independently read Fuel documentation.
  • NailgunSimpleDriver
    • bareon native partitioning input data driver. It is just a de-serializer for bareon PartitionScheme object.

In order to be able to use another specific data format one can implement his own data driver and install it independently. Bareon uses stevedore to find installed drivers. A new driver needs to be exposed via bareon.driver setuptools name space. See for example setup.cfg file where entry points are defined.

One can also take a look at contrib directory for some additional examples.

How to install

Bareon can be installed either using RPM/DEB packages or using python setup.py install.


Bareon currently follows openstack contribution guidelines.

Core Reviewers