Edit ( 2015-10-07): Some changes have happened recently in TripleO that have obsoleted the templates below. I've created a Git repo for the templates so it is easier to keep them up to date: https://github.com/cybertron/tripleo-network-templates The discussion below is still relevant, but the actual template snippets won't work in a current TripleO setup so they need to be replaced with the ones from Github.
It turns out I've had spammers registering accounts on this site for quite a while now. Fortunately, I require admin verification of any new accounts, so none of the spammers got anywhere. Unfortunately, I had failed to configure my email address, so I wasn't getting notified of any user registrations.
Configs updated 2017/2/28 to reflect what I'm using now.
As part of my continuing investigation into QuintupleO, I've been playing around with multi-node devstack to see how QuintupleO works across multiple compute hosts. The good news is that the answer is "quite well" (another blog post on that topic is probably needed as well), and since some of the devstack multi-host documentation I found through Google was a bit out of date, I thought I'd go ahead and post what I've been using for my devstack setup.
Yes, it's still a thing.
Evidently there is a belief out there that TripleO died this cycle (which is understandable, in some ways), but I assure you we are still hard at work on it. In fact, there are some big changes in progress as I write this.
Third time's a charm, right?
Well, yes and no. Overall I would call the summit a success, and a lot of good things came out of it. It wasn't all sunshine and puppies though, and there are definitely some things I personally, and we as a community, could improve. Which means I should have lots of interesting things to talk about in this post. Let's get right to it.
As promised, here is the demo video for QuintupleO.
Yep, that's right. I've successfully deployed a cloud in a cloud using a third cloud. I have a video, but I'm not sharing it just yet because it was done using some slightly broken pre-release overcloud images. On the plus side they had exactly the same issues as the non-QuintupleO environments so I'm declaring success. :-) As soon as I have a chance to re-record with a fully functioning overcloud I'll post it here.
As discussed in my last update on QuintupleO, the biggest blocker for getting that working was a way to allow Ironic to control OpenStack instances. Since then I have been made aware of the pyghmi project, which provides a way to implement IPMI interfaces that do arbitrary things on the back end. It currently includes a couple of examples in its bin directory for noop and virsh implementations.
I've discussed my local OpenStack installation before, such as here and here. One of the results of the changes I've made to it over time is that I have some instances that are booted from volume. Unfortunately, instances booted from volume don't snapshot properly with the nova image-create. Below is the quick and dirty method I've been using to take snapshot backups of those vms for a while now.
Edit Jan. 26, 2015: After discussing this with the Oslo team some more, I discovered that almost everything I said here was already covered quite well in the drop namespaces spec (that I reviewed... ;-). You're probably just as well off going and reading that, but I'm going to leave this here just in case it happens to help get the word out.
During the Kilo cycle the Oslo team has been busy deprecating the oslo. namespace in all of our projects. The first question this probably raises for most people is: why? Unfortunately the answer to that is not simple, and I'm not sure I understand some of the deeper details of it myself. However, after having talked to some of the Python packaging folks that hang around the OpenStack project we came to the conclusion that namespace packages in Python 2 are just too broken for us to continue using them.
