OVB

My TripleO Development Workflow

I have complained extensively over the past couple of years about the over-automation of developer environments in TripleO. But wait, you say, isn't automation a good thing? And yes, it is, but the automation needs to happen in the right places (feel free to append "IMHO" to anything in this post ;-). The problem with a bunch of developer-specific automation is that it hides very real user experience problems because the developers just use their simplified interface and never touch the regular user interface. Essentially it's the opposite of dogfooding, which is something I feel is critical to writing good software. This is also known as the "Works in Devstack" problem for OpenStack as a whole (I will not be tackling that problem here though).

So if I don't like what most people are doing today, what would I prefer? That will be the topic of this post. I'll discuss what I do, and possible areas for improvement.

OpenStack Virtual Baremetal Usability Improvements

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.

Prevent cloud-init from Changing Your Hostname on Reboot

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.

Improving TripleO CI Throughput

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.

New Features and Better Documentation for OVB

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.

Over 20000 OVB CI Jobs

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". :-)

Video of OVB Running Against a Stock OpenStack Cloud

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.

Musings on the Austin Summit

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

OVB Network Diagram and Update

Status

It's been a while since my last OVB update, and I've been meaning to post a network diagram for quite a while now so I figured I would combine the two.

In general, the news is good. Not only have I continued to use OVB for my primary TripleO development environment, but I also know of at least a couple other people who have done successful deployments with OVB. There is also some serious planning going on around how to switch the TripleO CI cloud over to OVB to make it more flexible and maintainable.

QuintupleO is now OpenStack Virtual Baremetal

Because every decent project related to OpenStack has to go through at least one rename. ;-)

Actually there are practical reasons behind this rename. First, it turns out a lot of people think you're joking if you start talking about QuintupleO (and to be fair, the name started out as a very tongue-in-cheek thing). More importantly, OpenStack Virtual Baremetal has applications outside of just TripleO, which is a fact that tends to get lost in the Stack-ception of the old name.

Subscribe to RSS - OVB