OVB

OpenStack Virtual Baremetal Imported to OpenStack Infra

As foretold in a previous post, OVB has been imported to OpenStack Infra. The repo can now be found at https://git.openstack.org/cgit/openstack/openstack-virtual-baremetal. All future development will happen there so you should update any existing references you may have. In addition, changes will now be proposed via Gerrit instead of Github pull requests. \o/

OpenStack Virtual Baremetal Master is Now 2.0-dev

As promised in my previous update on OVB, the 2.0-dev branch has been merged to master. If this breaks you, switch to the stable/1.0 branch, which is the same as master was prior to the 2.0-dev merge. Note that this does not mean OVB is officially 2.0 yet. I've found a couple more deprecated things that need to be removed before we declare 2.0. That will likely happen soon though.

OpenStack Virtual Baremetal Import Plans

There is some work underway to import the OVB repo from Github into the OpenStack Gerrit instance. This will allow us to more easily set up gate jobs so proposed changes can be tested automatically instead of the current "system" which involves me pulling down changes and running the test script against them. It will have some implications for users of OVB in the near future, so this is a summary of the plans and actions that need to be taken.

Openstack Virtual Baremetal 2.0 Update

As mentioned in a previous update, OVB 2.0 is coming. This update to is to notify everyone that a development branch is available in the repo and discuss some of the changes made so far.

OVB 1.0 and Upcoming Changes

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

OpenStack Virtual Baremetal on a Public Cloud

Background

At long last, OVB has reached the goal we set for it way back when it was more idea than reality. The plan was to come up with a system where we could test baremetal deployment against OpenStack instances in an arbitrary cloud. That would allow something like TripleO CI to scale, for all practical purposes, infinitely. For years this wasn't possible because OVB required some configuration and/or hacks that were not appropriate for production clouds, which limited it to use in specific CI-oriented clouds. Theoretically it has been possible to use OVB on normal clouds for a couple of years now, but in practice public clouds were either running OpenStack versions that were too old or didn't expose the necessary features. Fortunately, this is no longer true.

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.

Pages

Subscribe to RSS - OVB