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