[openstack-dev] [TripleO] Easier way of trying TripleO

James Slagle james.slagle at gmail.com
Tue Nov 19 21:40:40 UTC 2013


I'd like to propose an idea around a simplified and complimentary version of
devtest that makes it easier for someone to get started and try TripleO.  

The goal being to get people using TripleO as a way to experience the
deployment of OpenStack, and not necessarily a way to get an experience of a
useable OpenStack cloud itself.

To that end, we could:

1) Provide an undercloud vm image so that you could effectively skip the entire
   seed setup.
2) Provide pre-built downloadable images for the overcloud and deployment
   kernel and ramdisk.
3) Instructions on how to use these images to deploy a running
   overcloud.

Images could be provided for Ubuntu and Fedora, since both those work fairly
well today.

The instructions would look something like:

1) Download all the images.
2) Perform initial host setup.  This would be much smaller than what is
   required for devtest and off the top of my head would mostly be:
   - openvswitch bridge setup
   - libvirt configuration
   - ssh configuration (for the baremetal virtual power driver)
3) Start the undercloud vm.  It would need to be bootstrapped with an initial
   static json file for the heat metadata, same as the seed works today.
4) Any last mile manual configuration, such as nova.conf edits for the virtual
   power driver user.
6) Use tuskar+horizon (running on the undercloud)  to deploy the overcloud.
7) Overcloud configuration (don't see this being much different than what is
   there today).

All the openstack clients, heat templates, etc., are on the undercloud vm, and
that's where they're used from, as opposed to from the host (results in less stuff
to install/configure on the host).

We could also provide instructions on how to configure the undercloud vm to
provision baremetal.  I assume this would be possible, given the correct
bridged networking setup.

It could make sense to use an all in one overcloud for this as well, given it's
going for simplification.

Obviously, this approach implies some image management on the community's part,
and I think we'd document and use all the existing tools (dib, elements) to
build images, etc.

Thoughts on this approach?  

--
-- James Slagle
--



More information about the OpenStack-dev mailing list