BLOG.info(self)

One of the unintended consequences of Feature Freeze in OpenStack is that a lot of new features get merged in a hurry at the end of the cycle. That's obviously not ideal, but it's a reality we all have to live with for now. TripleO has been bitten by this a few times recently, and the long gate queue that also goes along with Feature Freeze means sometimes fixes for problems take a long time (days) to merge in the other projects. In the gate we have tempreverts and cherry-picks to mitigate that problem, but for local devtest those features are not available. Fortunately there's another solution.

I've recently been trying to enable the Dracut deploy ramdisks I posted about earlier for RHEL7. I've been running into some issues that weren't present on the other platforms I've tested so far, and because of that I want to ask for some help from some Dracut experts. Unfortunately, the problem I'm having occurs so early in the Dracut boot process that it hasn't started any device management yet, so attaching a disk to collect logs doesn't work immediately.

A little less than a year ago I picked up an old Dell CS24-SC 1U server from EBay. It's got a ton of power - dual quad core, 24 GB of RAM, 4 146 GB 15k SAS drives, and an integrated BMC. That last is something I've struggled with though. Because this is a server, I really don't want to leave a keyboard and mouse plugged in to it all the time. Unfortunately, I haven't been able to get the remote KVM functionality working. Until now, that is.

For TripleO I was tasked with enabling our deployment ramdisks to be built with Dracut. There are a couple of reasons we want to do this.

I attended my first OpenStack Summit in Atlanta last week, and now that I'm (mostly) recovered I wanted to write down some of my thoughts about the experience.

The first security update for Drupal since I started this blog was released a while back, and I negligently dragged my feet in actually applying it here because I was unsure how to do so in OpenShift. It turns out to be quite simple, but it did take me a while to figure out all the steps so I figured I would write them down here to help anyone else doing the same thing.

I said in a previous post that I would write something up about my devtest workflow once I had it nailed down a bit more, and although it's an always-evolving thing, I think I've got a pretty good setup at this point so I figured I'd go ahead and write it up. Instead of including scripts and such here, I'm just going to link to my Github repo where all of this stuff is stored and reference those scripts in this post.

Just ran into an issue running tox in diskimage-builder on a CentOS 6.5 instance I booted to test a change that failed the python26 gate test, so I thought I'd post the fix in case anyone else hits the same thing.

A full run of TripleO's devtest takes a long time - around an hour or more on my i7/16GB box even with a hot squid cache. Quite a bit of the time is spent building images, and there are a few ways to speed that up, some of which are easier than others.

I've been meaning to write something up about how I set up my OpenStack development environment because there are some handy things you can do before you even get started that will likely save you some hassle down the line. I've recently discovered that there are rather varied ways other people are doing this sort of thing, so keep in mind that this isn't the "right" way, it isn't the best way, but it's what works for me.