Open Stack

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.

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.

>
> 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.

>
>> At the very least, this could be an easier way for developers to get
>> setup with tripleo to do a test overcloud deployment to develop on
>> things like Tuskar.
>>
>
> Don't let my questions discourage you. This is great as-is!

Great, thanks.  I appreciate the feedback!


-- 
-- James Slagle
--