BLOG.info(self)

By default the overcloud-full image built as part of a TripleO deployment does not have a root password set. Sometimes it can be useful to set one, particularly if you're having network setup trouble that prevents you from ssh'ing into the instance after it's deployed. One simple way to do this is as follows:

sudo yum install -y libguestfs-tools
virt-customize -a overcloud-full.qcow2 --root-password password:password
. stackrc
openstack overcloud image upload --update-existing


Just a quick note about the latest OVB news. First is that the docs are no longer one big flat README file. This should make them much more consumable. The shiny new docs are being published at Read The Docs.

You may also note that there are some new bits in these docs. Some of these (like QuintupleO deployments) are not really new but were previously undocumented. Others (heterogeneous deployments) are actually pretty new. There are more details about both in the docs. As always, let me know if you have any feedback.

Just a quick note that we recently surpassed 20000 OVB test envs started on the rh1 TripleO test cloud. This number only represents how many test envs have been created since the testenv broker was last restarted (which resets the count), but it's still impressive. The overall total between the rh2 cloud and pre-broker-restart rh1 envs is probably closer to double that, based on my highly unscientific counting method of "I think that's about how many we had started before". :-)

I've been meaning to do something like this for about 3 years and finally got around to it. It's a video series in which I go over a number of common Git and Gerrit activities for doing OpenStack development. As I mention in the intro, this isn't intended to be Baby's First Git/OpenStack Tutorial (although I do go over some pretty basic stuff) because there are other resources for that. What it is intended to cover is the stuff I periodically see questions about from other OpenStack developers. I'm hoping it will be helpful for new and even more experienced developers.

There are times where it can be handy to test an undercloud install in a standalone VM. For example, if you're working on installing a new service, or upgrading the undercloud, many times you can make progress in a lighter weight single VM environment. Obviously the undercloud won't be usable for anything if it's not part of a full virt environment, but you can at least check that a service is running at the end of the install and do some basic sanity checks.

I've finally gotten around to recording a demo of the current iteration of my tool to generate TripleO network isolation templates. You can watch the demo video (in which I say "umm". A lot. Sorry.) or check out the tool itself. There are also some templates generated with the tool if you want examples to start from.

This is sort of a PSA for something that has been available for quite a while. I run a Jenkins job locally that does RPM builds of proposed changes to a number of TripleO repos. This can be helpful if you want to test a change locally as it means you don't have to pull the code down and do a build yourself. Just sudo yum install -y https://repos.fedorapeople.org/repos/openstack-m/jenkins/rpm-build/333121/4/instack-undercloud-999.9.9-99999.noarch.rpm (for example) and you've got the change installed.

I had hoped to have this ready before the Austin summit, but...it didn't happen. Even so, this is the latest big advancement in OVB. It's now possible to do a baremetal-style deployment to OpenStack instances in a completely unmodified OpenStack cloud. Here's video proof: OVB on a stock OpenStack cloud.

This is going to be a bit of a different summit recap than my previous ones. Since Steve Hardy has already posted an excellent summary of the major TripleO topics from this summit, I'm not going to duplicate all of that here.

Instead, this will be a more personally focused post, wherein I reflect on my experience at this summit and how it compared to previous ones. If that kind of navel-gazing sounds incredibly uninteresting, then you might want to pull the rip cord now. :-)

One of the first things a new user of TripleO has to do is write a configuration file for their undercloud. While this is not as complex as, say, writing a nova.conf, there is still some level of difficulty due to the need for consistency between different options, and some less than ideal overlap/inconsistency between the options themselves. In the interest of easing new users' introduction to TripleO as much as possible, I've written a tool to help create undercloud.conf.