I wanted to take a few minutes to go over the progress we've made with TripleO Puppet in Kilo so far.
For those unfamilar with the efforts our initial goal was to be able to use Puppet as the configuration tool for a TripleO deployment stack. This is largely built around a Heat capability added in Icehouse called Software Deployments. By making use of use of the Software Deployment Puppet hook and building our images with a few puppet specific elements we can integrate with puppet as a configuration tool. There has been no blueprint on this effort... blueprints seemed a bit ridged for the task at hand. After demo'ing the proof of concept patches in Paris we've been tracking progress on an etherpad here: https://etherpad.openstack.org/p/puppet-integration-in-heat-tripleo Lots of details in that etherpad. But I would like to highlight a few things: As of a week or so all of the code needed to run devtest_overcloud.sh to completion using Puppet (and Fedora packages) has landed. Several upstream TripleO developers have been successful in setting up a Puppet overcloud using this process. As of last Friday We have a running CI job! I'm actually very excited about this one for several reasons. First CI is going to be crucial in completing the rest of the puppet feature work around HA, etc. Second because this job does require packages... and a fairly recent Heat release we are using a new upstream packaging tool called Delorean. Delorean makes it very easy to "go back in time" so if the upstream packages break for some reason plugging in a stable repo from yesterday, or 5 minutes ago should be a quick fix... Lots of things to potentially talk about in this area around CI on various projects. The puppet deployment is also proving to be quite configurable. We have a Heat template parameter called 'EnablePackageInstall' which can be used to enable or disable Yum package installation at deployment time. So if you want to do traditional image based deployment with images containing all of your packages you can do that (no Yum repositories required). Or if you want to roll out images and install or upgrade packages at deployment time (rather than image build time) you can do that too... all by simply modifying this parameter. I think this sort of configurability should prove useful to those who want a bit of choice with regards to how packages and the like get installed. Lots of work is still ongoing (documented in the etherpad above for now). I would love to see multi-distro support for Puppet configuration w/ TripleO. At present time we are developing and testing w/ Fedora... but because puppet is used as a configuration tool I would say adding multi-distro support should be fairly straightforward. Just a couple of bits in the tripleo-puppet-elements... and perhaps some upstream packages too (Delorean would be a good fit here for multi-distro too). Also, the feedback from those in the Puppet community has been excellent. Emilien Macchi, Yanis Guenene, Spencer Krum, and Colleen Murphy have all been quite helpful with questions about style, how to best use the modules, etc. Likewise, Steve Hardy and Steve Baker have been very helpful in addressing issues in the Heat templates. Appreciate all the help and feedback. Dan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
