LISA14 - Day Two

Today I sat in on Nathen Harvey's "Testing Your Automation Code" course.  Roughly speaking, it was divided into two parts: an introduction to configuration management with Chef, and then an exploration of the different ways to test your configuration management code.  Tests? You bet: while monitoring will tell you whether your servers and services are running as they should, code tests will give you confidence that your automation will work the way you want it to.  Sysadmins have already stolen revision control and automation from developers; while not steal syntax, unit and acceptance tests from them as well?

Much more than that, though, there was a lot of Q&A and discussion about the questions and assumptions underlying the course.  Why test our infrastructure code? Answers ranged from "I'm paranoid I'm going to break things" to "I need to demonstrate to others that the code does what I say it does" to "It's code, and it's just good practice to test your code." What kinds of tests do we need?  Harvey's response:  "I don't care if what we're doing is unit or acceptance or integration testing -- the test you write is much better than the one you don't."  How far down the stack do we need to verify (aka "Do I really need to test whether Puppet copied a file?").  Answer: Enough to make you happy; you can always go back and remove tests as you get more confident.   How do we make our tests flexible enough to accommodate changes in code, in targeted operating system, or even the tool we use for automation?  Answer: Spend less time testing, say, if Apache was installed (and thus having to test for package "httpd" on CentOS vs "apache2" on Debian), and think hard about whether you need more than that final happy output from "curl localhost" at the end. 

It was an excellent and informative time by a funny and engaging instructor, and the hands-on exercises (c/o hosted VMs) gave everyone a good sense of what is possible with Serverspec, Kitchen and Chef.  Harvey was good enough to post his presentation material, and I recommend reading it.

In the evening I went to the USENIX Women in Advanced Computing (WiAC) BoF, led by Carolyn Rowland.  Discussion centered around two main topics: how to bring women into technical fields, and how to change the culture of IT in order to keep women. Suggestions ranged from how to avoid taking criticism personally if you cause offense ("It's like a post-mortem: something I can learn from"), to how to make sure women's voices are heard in day-to-day interactions, to grass-roots efforts to increase education...though as Rowlands pointed out, sometimes it's easier to focus on bringing in more women than on dealing with why they leave in the first place, and both questions need our attention.

As you might expect, we didn't solve these problems -- a tough admission for a group of people that solve problems for a living.  But being aware of them in the first place, and the role you play (both good and bad), is a necessary first step.  (There are more women-focused events at LISA14 this week; be sure to check them out.)