The first talk, given by Nick, was on Infrastructure as Data and sort of felt like it had two main themes to it. The first of these took a look at what it means to "require" something and Nick used the good example of NTP package. Here he talked about the two directions a philosophical light cone of ideas can split from the this one requirement. On one side he showed the dependency tree of what requiring NTP really involves. He talked about the fact that installing NTP requires a package manager, which requires an OS, which requires electricity to run, which requires the physical notion of time. Most people chuckled at the level of detail in this dependency tree, but I bet the engineers at places like Google and NASA consider this sort of thing on a daily basis. On the other end of the light cone was the level of abstraction used to express what someone really wants when they require NTP. i.e. why do you want NTP? So your servers have a consistent time with the rest of the world. Why do you want your server time consistent? So that all your DB entries and metrics are meaningful among other things. Why do you want that? So that you can make proper business decisions based on your data. Why do you want that? So that... Puppet isn't quite at the point where you can tell it to "keep my server time in sync", but it might not be far off. Regardless, being able to specify infrastructure as business requirements rather than as data, let alone code, seems to be something that is very sysadmin friendly.
The second theme of the talk concerned the lack of higher level information associated with the relationship mechanism in the Puppet DSL. If you were going to move from infrastructure as data to infrastructure as business requirements then adding semantic information to relationships between models would greatly assist in this attempted abstraction. As I stroke my neckbeard I wonder what this means for Puppet users. If we ask developers to step back and see the forest from the trees in what our sysadmin brothers and sisters really want in a level of abstraction, we might be able to provide it for them given this possible extra flexibility in the language features.
I then stuck around for Spencer's talk on using Puppet Without Root, which I found fairly insightful, aside from the possible irony of having to mangle your machine's configuration just to get your configuration management tool to work without root access. As a developer I loved this talk - the level of resourcefulness in finding weird solutions to particular problems,
the level of niche operating system knowledge required to connect everything back up after dismantling it, and the general outside the box approach to a circumventing not having root access. I could, however, imagine the sysadmins or security guys in the audience cringing at the level of resourcefulness required to solve this problem, the level of niche operating system knowledge required and the outside the box approach to circumventing having no root access. As I stroke my neckbeard I worry for my sysadmin brothers and sisters using Puppet without root. It certainly needs to be made easier.
The next talk introduced Geppetto, an IDE for working with Puppet files with some really good integrations with the Forge and GitHub, among other things. Nothing screams "developer" like the terms "IDE", "syntax highlighting" and "GitHub integration". Luckily most of the audience, when asked if they knew what an IDE was and what the acronym stands for, raised their hands. Luckily these "developer types" are used to editing characters in files according to a particular syntax, to later be parsed by a program for correctness. Designing Puppet objects in the Puppet DSL isn't too much of a stretch. As I stroke my neckbeard I wonder what how the introduction of an IDE is received by a sysadmin Puppet user.
Just before the afternoon break, Nick gave a very enjoyable talk on his quest through the Puppet DSL. The unfortunate thing about this talk was that there were definitely not as many people present as there should have been. All the neckbeards had either gone to another talk, or their pull requests were beginning to pile up and they had to duck out for an hour to sort them out. As Nick introduced one language quirk after another I watched the audience react with a sense of mild confusion. People didn't seem to realise the underlying Rubyisms appearing the Puppet DSL. In particular, the everything is logical true slide stood out in helping me approximate the general programming level of the room. All these different variations of different data types all seemed to evaluate to true when "logic" would dictate that most of them should be false. If anyone there had coded in Ruby before they would know that most of these "quirks" were specifically "by design" in the Ruby language spec. You could see the underlying Rubyness of Puppet peek its head out. Without checking the Puppet source for proof, I bet there's a fair amount of ".to_s"s and ".join"s employed just under the surface to simplify things for the common Puppet user. As I stroke my neckbeard I wonder more and more about the average Puppet user's ability to use the Puppet DSL given how they reacted to bugs features of Ruby, of which many neckbeards don't acknowledge as a "real" language anyway.
After the break Jason gave a talk on Managing Cisco Devices Using Puppet. After learning about OpenFlow and Open Daylight in the last few months it's good to see onePK introduced as another SDN standard. Since it's hard to express sarcasm without downloading and installing a sarcasm font, I'll leave this discussion for another blog post. As I stroke my neckbeard I really like the idea of software defined networks because they give more power to the developer, but I worry for my network admin cousins. Are they going to have to learn to "code" too?
I then get to the final neckbeard talk of the day... Loops and Unicorns - The Future of the Puppet Language. The talk introduced new language features like iteration, lambdas, else-on-unless, more normal data types ("numbers are numbers now") and many other Rubyisms. I remember thinking to myself, Puppet is now Chef, or at least some sort of "almost Ruby". As a developer, I really appreciated this new freedom and I like that Henrik seemed to have a proper compilers/parsers/tokenizers/grammar background and knew what he was doing. However, as I stroke my neckbeard I again wonder what this means for the Puppet sysadmin user.
For a technology that has traditionally, and very successfully, been targeted at sysadmins, I wonder why Puppet is showing an increased focus on support for the development side of the DevOps equation. Are they looking to do enough to see off Chef or is it a change in approach? As long as the changes mean increasing Puppet's power and flexibility for those with development chops, without introducing an increase in complexity for those without them, it appears to be a solid strategy. That is, get developers to do what developers do best in the Puppet world - build modules. Get sysadmins to do what they do best and use those modules as generals of their infrastructure rather than sergeants. If this is the case then perhaps Puppet have worked out that the tool and community should be the medium of collaboration, rather than one that forces a bleeding of skill sets between different types of users.