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.
Edit: Updated 2015/3/19 with more current diffs of my changes.
At the Atlanta OpenStack Summit we had a session on something called QuintupleO, otherwise known as "TripleO wasn't confusing enough, let's add another layer" :-) Barring a few specific concerns from other teams, which I believe have now been addressed to their satisfaction, everyone seemed to be on board with the idea. But what exactly is QuintupleO, and where does it stand today? Read on to find out.
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.
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 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.
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.
