Jump to: navigation, search


Revision as of 21:45, 12 May 2014 by James Polley (talk | contribs) (Bug Triage)

TripleO - OpenStack on OpenStack

TripleO is a program aimed at installing, upgrading and operating OpenStack clouds using OpenStack's own cloud facilities as the foundations - building on nova, neutron and heat to automate fleet management at datacentre scale (and scaling down to as few as 2 machines).

We gave a presentation at the portland 2013 summit about TripleO.

TripleO is raw but usable today - see our tripleo-incubator for deployment instructions.

Folks working on TripleO are contributing to Nova, Neutron, Heat and Ironic to ensure they have the facilities needed to deploy to baremetal at scale. We also have a small number of projects we're shepherds for ourselves:

  • tuskar - stateful API for managing the deployment of OpenStack
  • tuskar-ui - UI and Horizon plugin for managing the definition of a cloud(s)
  • python-tuskarclient - API client for tuskar.


Our overall story is to invest in robust solid automation such that we can do continuous integration and deployment testing of a cloud at the bare metal layer, then deploy the very same tested images to production clouds using nova baremetal (now ironic), rather than any separate management stack, leading to shared expertise in both deployments in the cloud, and of the cloud. Finally, because we can setup OpenStack in a fully HA environment, we can host the baremetal cloud used to deploy OpenStack in itself, and have a fully self sustaining HA cluster. On top of that we intend to build out a solid operations story - baseline monitoring autoconfigured as the overcloud - the cloud we deploy on top of the bare-metal "under" cloud scales up.

TripleO contributor cloud

In order to validate our design we have our own continuously deployed cloud that any TripleO ATC can use.

Team responsibilities

As a team we have responsibility for the design and quality of the code we're creating, and to respond to critical bugs and security issues in that, do reviews, triage bugs and generally support our users.

However, we also have things we haven't released yet that are in the same codebases, and we don't want to run ourselves ragged treating every bug as a regression, unless it's actually in something we've delivered and are maintaining.

Maintained features/projects

Regressions in these things are firedrills which (as a team) we need to hop on and fix ASAP. If you find one please report it to use as a Critical bug on https://bugs.launchpad.net/tripleo/+filebug. If you're a TripleO contributor and you find one, or see that one has been reported, please add a Firedrill card to the [TripleO kanban] (Kanban is an experiment at the moment, but so far we're finding it pretty useful).

If a particular TripleO endeavour isn't listed here, it's not yet supported. If you want it to be supported, add a item for it to the next TripleO meeting

  • diskimage-builder
  • os-collect-config
  • os-apply-config
  • os-refresh-config
  • tripleo-image-elements
  • tripleo-heat-templates
  • The TripleO Cloud MVP2 : ATC's should have usercodes, and the cloud resets entirely every hour.
  • toci identified devtest story issues *within the TripleO code*. We'll move to supporting everything when we're in the integrated gate

Stable releases of OpenStack

The process for doing releases of our Python packages is documented at TripleO/ReleaseManagement.

We have a nascent plan to provide [stable branches]of tripleo-incubator - like other OpenStack projects, which should be going live very soon.


A key goal of ours is to play nice with folk that already have deep investment in operational areas - such as automation via Chef/Puppet/Salt, or monitoring via icinga/assimilator etc. We're ensuring we have clean interfaces that alternative implementations can be plugged into [e.g. you can use Chef/Puppet/Salt to do the in-instance configuration of a golden TripleO disk image].


All tripleo blueprints. When creating new blueprints please ensure you put 'tripleo' in the short name.

Review team

Anyone can do reviews, but only the 'tripleo-core' team can approve them to land. We operate with the OpenStack standard two x +2's except in well, exceptional circumstances. Where multiple people collaborate on a single patch, one of the +2's must come from someone that isn't an author of the patch.

Please don't send requests for reviews to the mailing list. Try IRC or email instead. http://lists.openstack.org/pipermail/openstack-dev/2013-September/015264.html

As a guideline, we follow the standard Review Checklist.

The review team should look for reviews in all the following projects:

For simplicity, the following URL will show you reviews from the above projects that are open:

Bug Triage

Triage for us consists of:

  • assigning an importance
  • putting any obvious tags (e.g. 'baremetal') on it
  • setting status to 'triaged'.

(If you're a TripleO contributor and you're filing your own bug, you can skip 'confirm' and go straight to triaged - unless you believe the bug isn't real, in which case why are you filing it? :)

The bug triage team for TripleO is https://launchpad.net/~tripleo.

We're mostly using the process described at https://wiki.openstack.org/wiki/BugTriage, with two key differences:

  • we don't use wishlist: things we'd like to do and things that we do wrong are both defects; except for regressions the priority of the work is not affect by whether we've delivered the the thing or not, and using wishlist just serves to flatten all the priority of all unimplemented things into one bucket: not helpful.
  • we use triaged, not just 'confirmed'.

Notes for new developers

https://etherpad.openstack.org/p/tripleo-newdev-notes may contain further draft notes that haven't been added here yet

Creating accounts

Read and follow https://wiki.openstack.org/wiki/How_To_Contribute#If_you.27re_a_developer - you'll want to:

To make sure your contributions are attributed to your employer , you'll want to add your address to:

Read https://wiki.openstack.org/wiki/Gerrit_Workflow. It's a lot simpler than it looks! You'll need to follow the workflow in order to get the above changes approved. Don't try to remember it all at once - it's simpler to keep refer to it as you walk through your first review.

Ask in #tripleo for someone to add you to https://trello.com/tripleo so you can be added to the board at https://trello.com/b/0jIoMrdo/tripleo

Helpful infrastructure

Before you begin, you probably want to have a few other bits of infrastructure in place:

  • Lots of things call out to the internet to download things. Unless your internet is uber-fast, you'll probably find that setting up a squid proxy with the config at http://docs.openstack.org/developer/tripleo-incubator/devtest_setup.html#f3 will make your second and subsequent runs much faster.
  • If you have an ubuntu mirror close to you, you'll probably want to set DIB_DISTRIBUTION_MIRROR to point at it. If you don't, or if you're more bandwidth-constrained than disk-space-constrained, you might find it worth your time to use apt-mirror to create a local mirror.
  • Similarly, creating a pypi mirror will speed things up.
  • You'll almost certainly want to add the pip-cache and pypi-mirror elements to DIB_COMMON_ELEMENTS in order to avoid re-downloading python requirements.
  • To save these settings, create a file called ~/.devtestrc - devtest.sh will source this file automatically. If you're running the devtest_*.sh scripts by hand, remember to source this before you source devtest_variables.sh:
   export http_proxy=
   export DIB_COMMON_ELEMENTS="stackuser pip-cache use-ephemeral pypi-mirror"
   export DIB_DISTRIBUTION_MIRROR=http://local-apt-mirror.com/ubuntu
   export PYPI_MIRROR=http://my_local_pypi_url/simple 

Read through the diskimage-builder README.md (https://git.openstack.org/cgit/openstack/diskimage-builder/tree/README.md) - especially the section on "Debugging elements", which will help you debug problems that happen during image builds.