- 1 TripleO - OpenStack on OpenStack
- 2 Design
- 3 Team responsibilities
- 4 Interoperability
- 5 Blueprints
- 6 Review team
- 7 Bug Triage
- 8 Notes for new developers
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:
- tripleo-incubator (docs)- our incubator - new code lives here until we decide what the right long term home for it is.
- os-collect-config - collect and cache metadata, run hooks on changes. See OsCollectConfig
- os-apply-config - small templating layer for writing out config files.
- os-refresh-config - react to heat metadata changes and send heat events
- os-cloud-config - common code for tuskar and the seed initialisation logic, the post heat completion initial configuration of a cloud
- os-net-config - minimal tool to configure networking declared via platform-independent JSON on hosts
- diskimage-builder - build golden disk images
- dib-utils - pieces of diskimage-builder that are useful without the full project
- tripleo-image-elements - rules for diskimage-builder for OpenStack golden images.
- tripleo-heat-templates Heat templates for deploying OpenStack
- tripleo-ci - CI glue for TripleO
- Tuskar - Tuskar is a stateful API and UI for managing the deployment of OpenStack
- tripleo-specs - Specifications for upcoming TripleO functionality.
- tripleo-common - A common library for TripleO CLI and Tuskar UI
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.
See a basic architecture overview for additional information.
TripleO contributor cloud
In order to validate our design we have our own continuously deployed cloud that any TripleO ATC can use.
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.
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
- 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.
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. We also have an expedited approval process for changes where there is general consensus and only minor implementation changes are needed. Details can be found in the TripleO Review Guidelines.
For specs, we have some additional guidelines Spec Review Guidelines
The review team should look for reviews in all the following projects:
As a handy way to see all the reviews that need action, try the TripleoO Inbox Dashboard from https://github.com/stackforge/gerrit-dash-creator/
For completeness, the following URL will show you reviews from the above projects that are open:
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
You'll need to have git installed and working.
Many of the tools TripleO uses are written in Python, so you'll need a working install of that. The default version provided by your OS is fine, provided you're on one of our tested platforms.
We also rely on tox. To install it, run:
sudo pip install tox
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 element 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=http://192.168.5.61:3128/ export DIB_COMMON_ELEMENTS="stackuser common-venv pip-cache use-ephemeral" 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.rst (https://git.openstack.org/cgit/openstack/diskimage-builder/tree/README.rst) - especially the section on "Debugging elements", which will help you debug problems that happen during image builds.
So you want to start contributing to TripleO? Fantastic, and welcome to the team! Here are some of the things you're going to need to set up in order to start contributing to the project.
Read and follow https://wiki.openstack.org/wiki/How_To_Contribute#If_you.27re_a_developer - you'll want to:
- set up an account in Launchpad
- get added to the tripleo team (https://launchpad.net/~tripleo) so you can (self) triage bugs
- join the Foundation (https://www.openstack.org/join/)
- sign the ICLA
- add SSH keys to launchpad *and* gerrit
To make sure your contributions are attributed to your employer , you'll want to add your address to:
- One of the files under https://git.openstack.org/cgit/openstack-infra/gitdm/tree/openstack-config/groups
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.