Ever since I became a product manager at Chef in January, I’ve observed a fair amount of confusion and uncertainty in our industry about the role of product management. Although this is my first job as a product manager, I now have enough of a grasp of the responsibilities that I can offer a succinct explanation of the role (so if you’re reading this, dad, you now know what the heck I do.)
One of my last projects for 2014 is to move Chef off our old Sympa mailing list server to Google Groups for Business. This migration was codified in Chef RFC 028 a few months ago, but we wanted to hold its implementation until the migration to the chef.io domain was completed.
Moving the list of subscribers is fairly straightforward, but migrating the list archives has been enough of a chore that I thought I would document the required steps. This way, if anyone else is faced with a similar task, they do not need to spend hours Googling and/or banging their head against the wall of the Google Groups Migration API, where there are dragons — lots of them. Continue reading
I often get asked how to automate host naming and/or DNS records using Chef. In fact, there was an individual in IRC today who asked some variation of the same question I always get:
Currently I set hostnames on my nodes by looking up the ip from ifconfig and doing a reverse DNS lookup on that IP. It turns out this is painful since my upstream never sets the rDNS correctly without nagging. I’m thinking of just building a “nodes” data bag with IP -> hostname mapping. Is there a better way to do this?
Often I’ve answered people by telling them that if they’re using configuration management, the names of their hosts are completely irrelevant. They shouldn’t even bother adding them to DNS or to even care what their names are. I thought I’d explain my rationale behind this and why host names are largely unnecessary if you’re using a configuration management tool like Chef. Continue reading
A month ago, I presented a webinar entitled “Cooking on Windows with Chef” that demonstrates the power of Opscode Chef on Windows. If you missed the webinar, you can watch that recording here.
One major way in which Windows has lagged Unix/Linux is in the desktop-based virtual machine development model using tools like VirtualBox and Vagrant. Vagrant, if you’re not already familiar with it, allows you to bring up and tear down development environments very quickly, and provision (configure) them using the same Chef cookbooks with which you’d configure your actual production environments. To that end, a bunch of folks have released an updated version of the vagrant-windows plugin, which adds WinRM and native shared folder support between Windows guests and the host operating system. Vagrant-windows has actually been around for a while, but had to be updated to deal with the API changes between Vagrant 1.1 and 1.2. This took a significant amount of work. Continue reading
I’ve been really busy working with our customers on becoming better Chefs, but I was recently invited by Kevin Karwaski of the Chef-Boston meetup group to give a presentation on the state of Chef cookbook testing today. Here are my slides: I hope the video will be up soon.
By the way, I renamed the demonstration cookbook from “sauceproxy” to “sauceconnect” in preparation for uploading it to the community site. Having unit and acceptance tests that I could run — both manually and via Travis — to verify that I’d done the search-and-replace properly really helped!