Difference between revisions of "TripleO"
m (s/quantum/neutron/) |
(add Tuskar things.) |
||
| Line 8: | Line 8: | ||
Folk working on TripleO are contributing to Nova, Neutron, Heat and [[Baremetal|Ironic]] to ensure they have the facilities needed to deploy to baremetal at scale. We also have a small number of projects we're shepards for ourselves: | Folk working on TripleO are contributing to Nova, Neutron, Heat and [[Baremetal|Ironic]] to ensure they have the facilities needed to deploy to baremetal at scale. We also have a small number of projects we're shepards for ourselves: | ||
| − | * [https://github.com/openstack/tripleo-incubator] - our incubator - new code lives here until we decide what the right long term home for it is. | + | * [https://github.com/openstack/tripleo-incubator tripleo-incubator] - our incubator - new code lives here until we decide what the right long term home for it is. |
* [https://github.com/openstack/os-config-applier os-apply-config] - small templating layer for writing out config files. | * [https://github.com/openstack/os-config-applier os-apply-config] - small templating layer for writing out config files. | ||
* [https://github.com/openstack/os-refresh-config-applier os-refresh-config] - react to heat metadata changes and send heat events | * [https://github.com/openstack/os-refresh-config-applier os-refresh-config] - react to heat metadata changes and send heat events | ||
| Line 14: | Line 14: | ||
* [https://github.com/openstack/tripleo-image-elements tripleo-image-elements] - rules for diskimage-builder for OpenStack golden images. | * [https://github.com/openstack/tripleo-image-elements tripleo-image-elements] - rules for diskimage-builder for OpenStack golden images. | ||
* [https://github.com/openstack/tripleo-heat-templates tripleo-heat-templates] Heat templates for deploying OpenStack | * [https://github.com/openstack/tripleo-heat-templates tripleo-heat-templates] Heat templates for deploying OpenStack | ||
| − | * [https://github.com/openstack-infra/tripleo-ci] - CI glue for TripleO | + | * [https://github.com/openstack-infra/tripleo-ci tripleo-ci] - CI glue for TripleO |
| + | * [https://github.com/stackforge/tuskar tuskar] - Horizon plugin for managing the definition of a cloud(s) | ||
| + | * [https://github.com/stackforge/tuskar-api tuskar-api] - API for managing the definition of a cloud(s) | ||
| + | * [https://github.com/stackforge/python-tuskarclient python-tuskarclient] - API client for tuskar. | ||
=Design= | =Design= | ||
Revision as of 21:07, 24 September 2013
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.
Folk 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 shepards for ourselves:
- tripleo-incubator - our incubator - new code lives here until we decide what the right long term home for it is.
- os-apply-config - small templating layer for writing out config files.
- os-refresh-config - react to heat metadata changes and send heat events
- diskimage-builder - build golden disk images
- 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 - Horizon plugin for managing the definition of a cloud(s)
- tuskar-api - API for managing the definition of a cloud(s)
- python-tuskarclient - API client for tuskar.
Design
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.
Interoperability
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].
