Role-based Puppet with Hiera

This is a method of configuring machines with Puppet based on their roles. It's similar to Jordan Sissel's nodeless Puppet in that there are no individual node declarations, just a default node that assigns one class. That one class is responsible for including all the other classes based on what 'roles' are assigned to the node. One difference between this role-based puppet and Jordan's nodeless puppet is that I'm not using an ENC. Instead of an ENC I'm using Hiera to assign to roles and specify custom parameters for the nodes. I put together a demo of role-based puppet as a Vagrant configuration, which you can get on GitHub.

Here is what the default node looks like:


The role class searches Hiera for 'roles' and includes them:


In Hiera multiple roles can be assigned, and data can be added to customize the roles. In this case we are adding the 'role::lb' load balancer role along with 'role::base', and specifying how much memory memcached should use and how many nginx processes should run.


The roles then include the actual classes that do the work, in this case nginx and memcache. In the real world the role would probably do a lot more, like configure sysctl. The role can pass site specific parameters to the classes, but it can also rely on Puppet to lookup parameters in Hiera.

Site-specific roles and generic modules

Every site is different, but there is no reason that every company should have its own nginx module. Modules should be generic and customizable, they shouldn't make assumptions about how you want to configure something. Roles are site-specific, they bring together modules in the way your site uses them. Data in Hiera can then customize modules or roles in node-specific ways.

For example puppetlabs-nginx (and jfryman's nginx module that it's based on) configures a yum repo hosted on nginx.org, and they don't allow you to specify custom templates for configuration files. That means I would have to fork and customize the puppet module if I wanted to use my own yum repo with a version of nginx compiled with ngx_pagespeed. It shouldn't be that way. I forked puppetlabs-nginx and added parameters to use custom templates, I'm going to continue working on it to make it more generic while still being easy for the 90% use case. I would like Puppet to be as simple as Ansible for the easy cases, and still be efficient and powerful when you need to customize.

Python libraries should not be licensed under the GPL

GNU General Public License (GPL) is great. It has helped the computing world in huge ways. I don't think Linux would be where it is today if it weren't for the GPL requirement that people who distribute modified versions of Linux also release their modifications. The GPL is what is called a copyleft license, it means modified versions of GPL'd software must be released under the GPL or a GPL-compatible license. In this way the GPL is infectious, like a virus. If you release software that includes any GPL'd code, your software in now under the GPL, or your software is illegal. Your software cannot be licensed under a permissive open source license like the BSD or MIT licenses.

The viral nature of the GPL poses a problem for code libraries, because anything released that uses the library will have to be GPL licensed. Mercurial has a good explanation of how the GPL works. It's really easy to write a little web application to display info about your local Mercurial repositories, all you have to do is import hg and write 50 lines of code. But if you do import hg, and you release your code, it must be released under the GPL. This is fine for a major stand-alone application like Mercurial, but not for libraries that don't function on their own. I have been disappointed by how many Python libraries are licensed under the GPL, for example all the DHCP-related libraries I have found are GPL.

The LGPL

The GNU Lesser General Public License (LGPL) is specifically designed to be used by libraries, it allows a license-incompatible application to link to a LGPL'd library. I personally find the LGPL to be extremely confusing for non-C applications. The terms it uses like "linking" and "header files" don't make sense for most interpreted laguages like Python and Ruby. The confusion has led to the creation of the Lisp LGPL. The Free Software Foundation has tried to clarify this confusion for Java, but even their clarification is confusing.

"Applications use Java's “import” functionality to access classes from these libraries. When the application is compiled, function signatures are checked against the library, creating a link."

So in Java it works correctly because Java compiles and links? What about Python which compiles at runtime? Or combined/minified JavaScript? Twisted was originally licensed under the LGPL, then it was changed to the MIT License. In regards to choosing the LGPL, Glyph Lefkowitz the creator of Twisted, said:

"In that, the confusing wording of the LGPL as it regards Python code was an asset. It would be a halfway accurate statement that I selected the LGPL exactly because it doesn't make any sense."

I'm not a lawyer, but I agree, the LGPL doesn't make sense, if for no other reason than it has created all this confusion.

Real World Example

For a real world example lets look at MySQL. The MySQL database and libraries are licensed under the GPL, with a key exception, it allows linking from OSI-compliant open source software. That linking exception allows MySQLdb, the Python interface to MySQL to be dual-licensed under the GPL and the old Python License. The Python License is a liberal BSD-like license. As a result of the permissive licensing of MySQLdb, the extremely popular Django framework, licensed under a BSD License is able to use MySQLdb. And a cool project like Review Board, licensed under the MIT License is able to use Django. If MySQL didn't have the linking exception, MySQLdb, Django, and Review Board would all have to be GPL licensed.

More realistically if the MySQLdb team had decided to only license it under the GPL, Django and all other frameworks would not use it. Instead they would use a BSD-licensed alternative, and the MySQLdb project would die. The same is true in the Ruby world, Ruby on Rails is MIT licensed. If you are writing some really cool Ruby library, and you hope it's going to become uber popular and included in Rails, you better not license it under the GPL.

Your Choice

The developers of software have the right to choose what license they use, and I don't mean to sound like I'm telling them what to do. I understand many people strongly believe in the GPL, and they choose it knowing the full implications of it. But I think, or at least I hope that most open source developers writing libraries want their libraries to be as widely used and useful as possible. If that's the case, I strongly believe that BSD-like licenses, like the BSD 2-Clause License, MIT License, or ISC License are the way to go.