Open Stack

Excerpts from James Slagle's message of 2013-12-24 10:40:23 -0800:
> On Tue, Dec 24, 2013 at 12:26 PM, Clint Byrum <clint at fewbar.com> wrote:
> > Excerpts from James Slagle's message of 2013-12-24 08:50:32 -0800:
> >> I built some vm image files for testing with TripleO based off of the
> >> icehouse-1 milestone tarballs for Fedora and Ubuntu.  If folks are
> >> interested in giving them a try you can find a set of instructions and
> >> how to download the images at:
> >>
> >> https://gist.github.com/slagle/981b279299e91ca91bd9
> >>
> >
> > This is great, thanks for working hard to make the onramp shorter. :)
> >
> >> The steps are similar to the devtest process, but you use the prebuilt
> >> vm images for the undercloud and overcloud and don't need a seed vm.
> >> When the undercloud vm is started it uses the OpenStack Configuration
> >> Drive as a data source for cloud-init.  This eliminates some of the
> >> manual configuration that would otherwise be needed.  To that end, the
> >> steps currently use some different git repos for some of the tripleo
> >> tooling since not all of that functionality is upstream yet.  I can
> >> submit those upstream, but they didn't make a whole lot of sense
> >> without the background, so I wanted to provide that first.
> >>
> >
> > Why would config drive be easier than putting a single json file in
> > /var/lib/heat-cfntools/cfn-init-data the way the seed works?
> >
> > Do you experience problems with that approach that we haven't discussed?
> 
> That approach works fine if you're going to build the seed image.   In
> devtest, you modify the cfn-init-data with a sed command, then include
> it in your build seed image.  So, everyone that runs devtest ends up
> with a unique seed image pretty much.
> 

I had not considered this but it makes sense.

> In this approach, everyone uses the same undercloud vm image.  In
> order to make that work, their's a script to build the config drive
> iso and that is then used to make config changes at boot time to the
> undercloud.  Specifically, there's cloud-init data on the config drive
> iso to update the virtual power manager user and ssh key, and sets the
> user's ssh key in authorized keys.
> 

Is this because it is less work to build an iso than to customize an
existing seed image? How hard would it be to just mount the guest image
and drop the json file in it?

Anyway I like the approach, though I generally do not like config drive.
:)

> >
> > If I were trying to shrink devtest from 3 clouds to 2, I'd eliminate the
> > undercloud, not the seed. The seed is basically an undercloud in a VM
> > with a static configuration. That is what you have described but done
> > in a slightly different way. I am curious what the benefits of this
> > approach are.
> 
> True, there's not a whole lot of difference between eliminating the
> seed or the undercloud.  You eliminate either one, then call your
> first cloud whichever you want.  To me, the seed has always seemed
> short lived, once you use it to deploy the undercloud it can go away
> (eventually, anyway).  So, that's why I am calling the first cloud
> here the undercloud.  Plus, since it will eventually include Tuskar
> and deploy the overcloud, it seemed more inline with the current
> devtest flow to call it an undercloud.
> 

The more I think about it the more I think we should just take the three
cloud approach. The seed can be turned off as soon as the undercloud is
running, but it allows testing and modification of the seed to undercloud
transfer, which is something we are going to need to put work in to at
some point. It would be a shame to force developers to switch gears and
use something entirely different when they need to get into that.

Perhaps we could just use your config drive approach for the seed all
the time. Then users can start with pre-built images, but don't have to
change everything when they want to start changing said images.

I'm not 100% convinced that it is needed, but I'd rather have one path
than two if we can manage that and not drive away potential
contributors.