Open Stack

On Tue, 2013-11-19 at 16:40 -0500, James Slagle wrote:
> 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.

The question here for me is what are you proposing to use to create
this image? Is it something that could live in tripleo-puppet-elements
like we manage the overcloud package dependencies? Or is it more than
this? I'd like to not have to build another alternate tool to help
manage this.

What if instead of an undercloud image we just created the undercloud
locally out of containers? Similar to what I've recently proposed with
the heat all-in-one installer here: https://dprince.github.io/tripleo-o
nward-dark-owl.html we could leverage the containers composable service
work for the overcloud in t-h-t and get containers support in the
undercloud for free.

If you still want to run an undercloud VM you could configure things
that way locally, or provide an image with containers in it I guess
too.

I'm fine supporting an easier developer case for TripleO but I'd like
to ultimately have less duplication across the maintenance of the
Undercloud and Overcloud as part of our solutions for these things too.

Dan

> 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
> --
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev