Testing

Edit: It turns out this doesn't help as much as I thought. Jenkins ignores duplicate webhook calls, so this is only helpful if your Jenkins missed a call. I'm still searching for a decent way to re-run jobs on a Github repo. :-( I'm leaving the rest of the post in place because it still has some useful information in it.

The time has come to declare a 1.0 version for OVB. There are a couple of reasons for this:

1. OVB has been stable for quite a while
2. It's time to start dropping support for ancient behaviors/clouds

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.

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

Edit: Updated 2015/3/19 with more current diffs of my changes.

At the Atlanta OpenStack Summit we had a session on something called QuintupleO, otherwise known as "TripleO wasn't confusing enough, let's add another layer" :-) Barring a few specific concerns from other teams, which I believe have now been addressed to their satisfaction, everyone seemed to be on board with the idea. But what exactly is QuintupleO, and where does it stand today? Read on to find out.

As I mentioned in a previous post, about a year ago I picked up a 1U server from EBay to use as a local single-node OpenStack environment. In general I was quite happy with it, but at some point I got tired of paying for electricity to run a fairly power-hungry server that sits idle, or close to it, about 95% of the time. The fans also picked up an annoying whine somewhere along the line, so once I discovered how much more efficient a modern desktop processor would be, while actually performing better than the old dual server ones, I decided it was time for a new box. This post will be the story of my journey to get Tempest running in an acceptable fashion on it, and what I learned along the way.

Most OpenStack projects use a combination of tox, testr, and subunit to run their unit tests. This works fine as long as you don't have any simple errors in your code, such as a typo in an import or a missing closing paren. In those cases testr or subunit may swallow the error and you won't know exactly where it is (I hear this may be fixed in some version of the tools, but the one I'm currently using still has this limitation). To fix this, we need another way to run unit tests that will expose the actual error to us.