Next week is the OpenStack Liberty Design Summit in Vancouver and I’m really excited about all the TripleO related topics that will be discussed. The progress made over the last cycle has been quite remarkable! I anticipate the community really building on this momentum.
The puppet implementation in tripleo-heat-templates has really proved itself over the last few months. The maturity of the OpenStack Puppet modules has helped accelerate the TripleO integration. New roles for ceph nodes have been added, and a full HA deployment is almost nearly complete.
Much of the Puppet work is enabled by some very nice features in Heat. In particular, Heat Environments and their resource abstractions that allow you to swap in non-default implementations. This has enabled the Puppet implementation to be done as a new backend for the existing templates. Of course, SoftwareConfig and SoftwareDeployment resources are driving the application of the Puppet manifests themselves once the initial operating system is deployed via Nova and Ironic. All of the needed operating system and OpenStack distro packages are still pre-installed in the images, and Puppet runs to do the configuration and initial bootstrapping of services.
Building on the work done in the templates, there is an effort to deploy a container based TripleO Overcloud. While this is still relatively new, the initial plan is to integrate with the Kolla docker images and use the docker-compose SoftwareConfig hook to deploy the containers themselves. I anticipate a lot of discussion around these plans next week at the summit, so if you’re interested in this topic, I suggest trying to attend the related TripleO sessions and the contributor’s meetup on Friday.
Another big focus in Liberty will be enabling a more production oriented network configuration in TripleO. In particular, network traffic isolation — the ability to isolate and designate different networks for different types of traffic such as provisioning, API, data, storage, etc. The configuration is aiming to be quite flexible, allowing for a varying number of networks and interfaces. The interface configurations themselves are also flexible in configuring things like bonds and bridges as may be required.
Progress on Overcloud upgrades driven by Heat is also moving forward. Likewise, the ability to scale up (and down) a stack is also an important part of lifecycle management of a cloud. The workflow side of these features are being proposed to the tripleo-common library, as we need a new repository to house the code driving these operations. There will also be a Heat Work Session about lifecycle operations as it relates to TripleO next week.
One thing I hope to get some input on at the Summit is our TripleO tooling. As TripleO grows in its ability to deploy and manage production clouds, I think it’s important to consider those needs as it relates to users and operators. TripleO will always be about using OpenStack API’s wherever it can to deploy a cloud. However, I think it’s important to consider if there’s a point where additional common tooling would pay dividends in helping drive all those different API’s…especially as it relates to ease of use, on-boarding new users and devs, and integration. Our existing scripting — devtest — has proven to be useful at dev and test :-), as well as driving our CI, but, I think we should also consider what types of tooling (if any) we need to help tie things together into a more overall usable deployment and management tool.
As always, swing by #tripleo on freenode if you’d like to connect with the community. A good place to get started is the developer docs at http://docs.openstack.org/developer/tripleo-incubator/index.html, as well as the docs on getting started using Puppet and TripleO: http://docs.openstack.org/developer/tripleo-incubator/puppet.html
If you’re a RDO user, you may also like to check out RDO-Manager, which is the TripleO based deployment tooling for RDO.
Looking forward to seeing everyone that can make it at the Summit!
 Now an official OpenStack project! https://review.openstack.org/#/c/172112