BLOG.info(self)

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.

I was asked to look into integrating Ansible Tower with TripleO a while back. It actually wasn't that difficult to do, but I've finally gotten around to recording a demo video showing how. In this post I will also provide a brief overview of how I installed Ansible Tower.

My laptop has 12 GB of memory and is largely used for web, email, IRC, and ssh to other systems. You might think that would be sufficient. You would be wrong.

If you've been following my blog very closely you might notice it's been up and down occasionally over the past couple of weeks. You may also notice that I mentioned Drupal "fun" in my previous post. This was maybe a bit misleading as it wasn't really Drupal's fault, but Drupal did make it much easier to deal with.

Updated 2018-04-02 with another possible solution

I've been having lots of Drupal "fun" in the past week or two (more on that later), and I finally managed to fix an issue that had been bugging me for a while on a site I had previously migrated from Drupal 6 to 7. Specifically the update.php page was not working. This despite the fact that I was logged in as user 1.

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.

So you're writing a Python application and you want to talk to an OpenStack service. Or maybe even multiple services. A quick Google turns up something like python-novaclient, which provides a way to create an instance of a Nova client in Python. Great! We're done here, right? Not so fast, my friend.

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.