Open Stack

On Fri, 2016-08-19 at 15:31 -0400, Dan Prince wrote:
> 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

I had a good laugh when James pinged me about this on IRC this morning.

I must have sorted my openstack-dev folder incorrectly... for whatever
reason this message came to my attention on Friday evening so I decided
it worth a reply.

So a bit of mismatched context here... probably best to have a laugh and move along. :)

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
> 
> _____________________________________________________________________
> _____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev