Hi, I’m Eric Sorenson (eric0 on #puppet IRC), and in June 2012 I moved from being a community member and Puppet administrator in the field, to working at Puppet Labs as the Product Owner for our open source projects. At the time, my first goal was to help get a great release of the next major version of Puppet (code-named “Telly”) shipped to the world, which launched late last month. Now with the release of Puppet 3.0.1 — which addressed and fixed the biggest issues that our awesome community of early-adopters found in the 3.0.0 release — it seemed like a good time to blog from the rooftops.
I’m new to Puppet Labs, but I have been running Puppet in large-scale production operations since 2009 and, somewhat naïvely, felt like I had a good idea of what Puppet 3 was supposed to look like. There had been, after all, a few dozen bugs in Redmine over the past couple of years in which the “Target Release” field I’d seen James or Nigel set to “Telly” … it was going to fix all the bad behavior we’d all reported over the years, right? Well, not exactly.
The tough thing about major releases of popular products is that the burden of expectations becomes so great, there’s no way reality can measure up. In some cases (The Phantom Menace, Guns n’ Roses “Chinese Democracy”) when the release does come, it’s universally panned on its own merits; other times, the release might have been fantastic if it had come when it was promised, but the timing was such that it had already gone stale (Duke Nukem Forever).
Through some amazing work by the engineering team, Puppet 3 managed to avoid both of these traps by delivering powerful features and high-quality code, at the expense of some of those “fix the world” bugs I’d hoped we would be able to close. I hope to make the case in this blog post that we’ve built a Puppet release that we can all be proud of — both its contributors and those who use it to run their critical infrastructure.
We wanted Puppet 3 to be faster than earlier versions, and not just a little faster — we wanted it to scream. Nick Lewis fixed an important bug around unnecessary object creation, but there was still more work to do. A big part of the long gap between Telly RC3 (June) and RC4 (end of August) was due to some deep work Daniel Pittman completed on performance, which appears to have paid off — big time. Between serialization improvements, some efficiency work, and a deep understanding of the Puppet codebase, Daniel crafted performance gains significant enough that the operations infrastructure here at Puppet Labs saw catalog compilation times drop by 60%. In addition, Greg Dallavalle, a sysadmin at Wolfnet.com who put 3.0.0-RC6 into production to reduce high CPU usage on his puppetmasters, watched their load average plummet from 6 back to 1 serving multi-thousand resource catalogs. Execution times improved too — Daniel’s testing framework ran puppet apply to catch inefficiencies in both compile and application phases so Puppet agents as well as masters benefitted from the attention.
The New Hotness
RI Pienaar’s ticket and associated patch to add Rubygem support to Puppet (#7788) drew the fourth-highest number of votes ever, and combined with Andy Parker and Kelsey Hightower’s work getting the patch polished up and merged should be a great win for people who want to distribute Puppet integrations and extensions like Faces, which are aware of Gem dependencies and OS-native extensions.
Kelsey also coded the Hiera Data Bindings, which enables Puppet to automatically look up parameters to classes in Hiera. This eliminates the need for special $myvar = hiera("parameter","default") syntax and generally makes data/code separation integrated into writing manifests and modules.
Solaris and Windows users who run Puppet 3 no longer have to feel like they are playing catch-up with the Linux distributions. In fact, some features on Solaris like Zones and SMF have gotten some serious love in Puppet 3. On the Windows side, Josh Cooper has added an amazing package provider for MSI packages and now Puppet 3 queries the registry for installed patches / packages to return a list as similar to the “Add/Remove Programs” as possible.
Another awesome change: Puppet 3 fully supports running under Ruby 1.9.3. Those of you who work at cutting-edge Ruby shops no longer need to keep around a 1.8.x Ruby install just for Puppet. Conversely, Puppet 3 under 1.8.5 is no longer supported, but we’ve backported and packaged 1.8.7 for the most prevalent distribution that still uses 1.8.5 — so RHEL5 users should grab the puppetlabs-release RPM from yum.puppetlabs.com and enable the dependencies repo to upgrade their system Ruby to work with Puppet 3.
An important point about Puppet 3 is that it moves to Semantic Versioning, which means the 3.0 release is the time to remove code that had been deprecated, with the goal of eliminating exceptions and old syntax in the codebase. I built a query based on the telly_deprecation tag in Redmine to organize both the things that already emitted deprecation warnings in Puppet 2.7 as well as new things that we wanted to start deprecating in Puppet 3.
The most highly-visible deprecation in Puppet 3 is probably the removal of dynamic scope lookup. Please read Nick Fagerlund’s comprehensive writeup at that link for the full story; the practical upshot is that it really shouldn’t be that big of a change unless you use unqualified variables outside of their native scope. There’s been a lot of confusion around this change; regrettably, some of it was caused by a bug in the mid 2.7.x series (prior to May 2012) that erroneously emitted a dynamic scope warning. For users of 2.7.x who are thinking of upgrading but are worried about dynamic scope, please make sure you’re on 2.7.16 or greater before poking through your logs to find and fix warnings. It’s much less of a big deal than it seems.
Other important deprecations in Puppet 3 include:
- puppet kick mode — this still works (as of 3.0.1) but emits a warning. We really think if you want central push/triggered execution, you ought to be using Mcollective, so puppet kick is deprecated.
- Running the puppetmaster under Mongrel — when the Puppet project started, scaling Ruby web apps was a relatively new science. Now that things have stabilized, we need to reduce the surface area of support, and one facet of that is the environment under which the Puppet master runs. Rack app servers have pretty decisively won this battle so it’s time to cut the cord to Mongrel. (Note this is a hard deprecation, i.e. removed code, not a warning)
- File source urls that point at modules/mymodule/files/myfile.txt but don’t contain puppet:///modules/mymodule — using source urls that used the old namespaceauth.conf file issued a warning through 2.6 _and_ 2.7, but is finally gone. Make sure all your files include modules/ in their path if they aren’t in an explicit fileserver.conf entry; better yet, if you can, use the content attribute instead of source because it reduces round trips to the Puppet master.
We’re tracking issues that people run into upgrading from earlier versions here and have a list of backwards-incompatible changes here, so please review those documents, and, as always, upgrade responsibly! There’s a new document to help out with upgrading to Puppet 3.
With the performance improvements, the new features, and the cleanups, Telly was an excellent release. Huge thanks to the community members and the talented, dedicated developers who filed bugs and wrote code to help drive Telly’s development process to completion. I hope you find Puppet 3 as enjoyable and rewarding to run and hack on as I do.