Deploying latest TripleO using TripleO-quickstart
by Juan Antonio Osorio Robles
Preface (you may skip this)
I’ve been working with TripleO and somehow setting my development environment is usually quite painful. Mostly because I hadn’t been taking notes and always have to research again how to do it.
So in honor of the title of this blog; finally I will note it down.
For a long time I was using a great tool developed by Jiri Stransky, called Inlunch. This tool is great! But the desire from the community is to have a more supported tool which is easier to use.
tripleo-quickstart in the same manner as inlunch is an ansible-based tool to aid people getting a TripleO development up and running. And it’s great! Does a lot of the dirty work for you, and leaves you with a nice virtual setup coming from a stable branch.
So, lets clone and get into the tripleo-quickstart directory:
And so, getting a basic environment is as easy as:
Where $HOST is the hostname of the node you want to deploy to and –no-clone tells the script not to clone quickstart again. This will leave you with a working undercloud and with ready-made scripts to deploy an overcloud to virtual nodes that have already been made for you.
NOTE: that the host needs to be accessible without a password, so you’ll need to copy your key there beforehand.
Now, there are several configurations you can deploy TripleO with. Being HA a very common one, it’s just a matter of adding the –config parameter and a configuration file.
There are several configurations already made which you can use in the config/general_config directory .
Working in master
All this is quite nice already. Problem is, for a dev-environment, I want to use master.
Now, I can see there are several options for the releases, which can be found in the config/release directory. The options are:
liberty.yml master-tripleo.yml master.yml mitaka.yml
I didn’t get master-tripleo to work. So I guess ‘master’ it is.
This will leave you with a fairly new and working undercloud.
Even newer master
If we want to work with an even newer version, in the way that it’s done in the TripleO CI, we can use tripleo.sh.
So, logged in the undercloud machine:
At this point I encountered a weird error. With the keystone puppet manifest failing. By looking at the logs, I figured that the database wasn’t being updated; which means that for some reason the resource keystone::db::sync was not receiving a refresh. So after running keystone-manage db_sync manually, I was able to get the undercloud deployment command to work.
Besides a newer undercloud, I want my overcloud images to be updated:
And that’s that! The new images should be registered in the undercloud’s Glance, and you should be ready to go!
tags: tripleo - openstack