Open Stack

Excerpts from Martyn Taylor's message of 2013-08-22 04:23:55 -0700:
> Hi Sylvain,
> 
> We are currently working on design docs.  We'll be adding some 
> architecture diagrams and description to our documentation soon.
> 
> To answer your question re: provisioning and images.
> 
> In our currently implementation (which is very early days), we took 
> images that were built from by Triple O, namely the overcloud 
> non-compute and compute images and we use these directly.  in the demo 
> environment you seen in the video, we used Triple O CI to set up the 
> machine, register the relevant overcloud images with glance and so on.
> 
> In Tuskar, we lifted from TripleO a copy of the triple-o overcloud heat 
> template and made some modifications.  We split out the non-compute and 
> compute sections, this allows us to add multiple entries of each of the 
> non-compute and compute sections (based on what is registered in Tuskar) 
> we then add a section to enforce deployment of the particular images 
> onto particular bare metal machines.  (This allows us to match hardware 
> to OpenStack services).  We do this by using the force_hosts capability 
> in the nova bare metal driver: 
> https://blueprints.launchpad.net/nova/+spec/baremetal-force-node.
> 
> We also add some extra commands to the Heat template to registers 
> flavors and associates the flavors, host aggregates and baremetal nodes 
> in the overcloud nova control instance.  This allows us to tell the nova 
> scheduler to match any instance requests with flavors that were 
> registered with a resource class in Tuskar with particular hardware that 
> has also been added to that resource class.
> 

These one-time bootstrap things are difficult to coordinate. We've been
moving them out of the instances and into scripts which do it all via
APIs. It would be great to coordinate with you on all of this.

> As Tomas mentioned, our initial release is really just a Proof of 
> Concept.  We'll be working to add more complex features and probably 
> rework much of our "short cuts".  Our aim though is to contribute as 
> much as possible (or as much that makes sense) of Tuskar upstream into 
> TripleO or any other component that we utilize and extend and have 
> Tuskar really concentrate on how to utilize existing components to 
> manage and deploy an OpenStack at large scale.

Martyn, and the rest of the Tuskar team: This is awesome!

Thanks so much for sharing and working with us to make this happen. Please
let us know if there's anything more we can do for you in TripleO.

In case you aren't sending anybody, just a quite invite, it is not too
late to book travel to the TripleO sprint at the HPCS offices in Seattle,
Sep 16 - 20. :)