If you've looked at the OVB repo or docs recently you may notice that there have been some significant changes. This is a good news-good news situation: the changes are backwards compatible and if you use the new configuration method it's much easier to deploy with some of the more advanced options in OVB.
Just a quick update on the TripleO Network Isolation Template Generator. A few new features have been added recently that may be of interest.
This is something that periodically bites me when I'm doing deployments in OVB. Because I'm dealing with cloud instances, cloud-init runs on each reboot and one of the things it does is change the hostname to whatever Nova's metadata says it should be. This behavior is very problematic for something like an undercloud VM because it can change your hostname from, say, undercloud.localdomain to undercloud-test.novalocal when you reboot the VM.
I was recently copied on an email from a team with a lot of new contributors to TripleO that was wondering if there was any sort of tips or guidelines for writing specs. My initial reaction was "The spec templates tell you how to write them." Then I realized that if you haven't ever written a spec before you may not know that. So, with that said, here are some of my thoughts on spec writing:
Disclaimer: These are my thoughts and opinions only. This is not endorsed by TripleO or anyone else in the OpenStack community. I'm just writing it in the hopes that it will be helpful.
If you spend any significant amount of time working on TripleO, you have probably run into the dreaded CI queue. In this case that typically refers to the check-tripleo queue that runs OVB. Why does that queue back up more than the regular check queue and what can/have we done about it? That's what we're going to talk about here.
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.
