Vancouver Summit - Big Changes for TripleO

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.

Puppet

Historically, TripleO has tried to be as deployment tool agnostic as possible. This was an admirable goal, but it also made it more difficult to consume the good work being done by these other communities. After some deliberation with the team, we've decided to deprecate the image element based deployment method and focus on Puppet. Up to now we had been supporting both as first-class citizens, but we simply don't have the resources to continue with this.

Unfortunately that leaves us with only a single primary deployment method, which means Puppet-specific things will likely creep into other areas of the code. We're hopeful that the container work being done concurrently will prove to be another alternative deployment method, and force us to keep writing thing generically enough to support multiple tools. We have definite plans to get containers into TripleO during the Liberty cycle, so this was a plan everyone present was comfortable with.

Network Isolation

One thing TripleO has not historically supported is more complex networking setups. There were basically two networks: provisioning and (perhaps poorly named) ctlplane. While this works for proof of concept deployments, it's not acceptable for a real, production deployment where network traffic needs to be isolated for performance and security reasons. One of the major topics of this summit was how to implement this in Heat and Puppet. Dan Prince and Dan Sneddon have a fairly large series of patches working their way through review right now that will allow better configuration of the network in production, so one of the work sessions was devoted to walking through those changes to understand how they work.

This is cool (IMHO), because I feel like we're really pushing what Heat is capable of today, and that is driving new features into Heat to better support complex environments like TripleO (but also other use cases that need the same sort of flexibility). It's the virtuous circle at work, which is still one of the absolute core tenets of the TripleO program. By having a consumer of the OpenStack services so closely tied in to the OpenStack ecosystem, everyone wins.

Containers

Containers are the hot topic right now, and as noted above we are very interested in integrating them with TripleO. Some preliminary work has been done on this, and will continue through the next cycle. We believe we have some short and medium-term goals that should be achievable and will put us on a path to have containers as a first-class method of deploying with TripleO.

Devtest Replacement

Devtest was the initial implementation of the TripleO workflow, and it did its job as a proof of concept. However, we've reached a point where the fact that the primary interface for TripleO was written in Bash is a limiting factor for new contributors. It also severely limits the amount of unit testing we can do.

In the end, I think Devtest was a solid way to show off that OpenStack can deploy OpenStack, but we've moved beyond that being a selling point. I no longer care if users are saying "Oh cool, OpenStack is deploying OpenStack", I care if users are saying "TripleO is a great way to deploy OpenStack". To that end, we are planning to move upstream TripleO more in the same direction as RDO Manager. While RDO Manager does have both benefits and drawbacks relative to Devtest, we think addressing the drawbacks of RDO Manager will be easier than addressing the drawbacks of Devtest.

Hallway/Pub Track

This was a pleasant surprise for this summit. While I felt like some of my time usage was not so good during the day, it was largely made up for by good discussions over dinner and drinks after the official sessions were over. One example was Tuesday night when I was sitting with James Slagle (TripleO PTL) and Lucas Gomes (Ironic Core) at dinner. James and I were raising some bugs we had run into with Ironic, and most of Lucas's responses were "We just fixed that" or "We have patches in flight to fix that". It's tough to beat that for quick response times. :-)

That was hardly the only time I had a productive conversation outside of an official context, and I'm happy that I finally took good advantage of the hallway/pub track. Now I just need to figure out how to combine that with the productivity I had in sessions for the Paris summit. Every time I go to one of these I learn more about how to get the most out of them.

Conclusion

I had actually considered not doing a writeup for this summit, simply due to some tight deadlines I'm facing at the moment. However, after having done it I'm glad I did. I was a little down about my participation in the summit this cycle due to not feeling I was as productive as in Paris. After considering all that did get accomplished though, and the amount I learned from my mistakes, I'm left feeling like it was a good summit after all. Even if no one else finds value in this wall of text, it was worthwhile to me. :-)