Now that roles and profiles are in my control repo my RSpec tests are taking longer then ever. As of this writing the control repo contains 938 tests and I’m still a long way from 100% coverage. This really slows down the feedback loop when running tests. When running locally I often just run RSpec against a specific spec file rather then run the whole test suite, but I still wanted a way to speed things up in Bamboo. ...
I spent some time tackling technical debt in our Puppet code this week. The biggest outstanding item was implementing eyaml for protecting secrets in Hiera. I’d also been encouraging developers to contribute to the Puppet code base for some time, but they were restricted from the control repo due to some secrets kept in Hiera. This put a big damper on collaboration as Hiera is the data engine for our roles and profiles. Separate git repos were also used for the profile and role modules due to this workflow. ...
rnelson0 is walking through automated Puppet testing with Jenkins on his blog. I thought I’d highlight how you can use a similar workflow in Atlassian’s Bamboo application. This assumes you already have a working Bamboo setup and are familiar with the general process for testing Puppet modules with rspec. Create a new plan The first step is to set up a new plan to use for the testing. Click “Create” and then “Create a new plan” in the top menu bar. ...
Two days ago I finished our migration to Puppet 4. Overall I’d say the process was pretty painless. The gist of what I did start running rspec tests against Puppet 4 fix issues found in tests run the catalog preview tool and fix any issues found turn on the future parser on the existing master turn off stringify facts create new master and PuppeDB server migrate agents to new master Thankfully our code wasn’t too difficult to update and most of the forge modules we use had also been updated. ...
I’m learning ruby. Finding time to work towards this goal is proving difficult but I’m forcing myself to use ruby wherever possible to aid in my learning. I’ll be putting some of my lame code on here to chronicle my learning and hopefully get some feedback on how I can improve things. I recently came across a good opportunity when I needed to generate a list of nodes to use with the puppet catalog preview tool ...
We’re working to upgrade our infrastructure to Puppet 4 and are making use of the catalog preview tool to help identify code that needs to be updated. The preview tool in and of itself is handy, but the output it produces can be a bit daunting. During the “Getting to the Latest Puppet” talk at puppetconf they pointed out a tool that professional services uses to create a nice html version of the output. Naturally I got excited to use this, but discovered it doesn’t properly work with open source Puppet due to some hardcoded Puppet Enterprise paths. Fortunately it was only 3 lines to update! My fork is here if its useful to others. ...
I’ve poked a lot of fun at chatops but I have found some value in portions of the practice. Let me state upfront that I do not believe paying attention to the chat room all day and having your attention interrupted non-stop is a productive or healthy practice. I have found some big benefits to “chatops” however. Visibility Work that is done in the chatroom, or filtered into the chatroom, is visible to the whole team. This helps the team be aware of what others are doing and stay up to date. I’ve picked up on quite a few things from this that I wouldn’t have learned other wise. This is also why we choose to route a fair amount of notifications into chat. For example we have Jira connected to HipChat and it makes it really easy to stay on top of issues. We also push commit notifications, build notifications, etc in the chatroom. The downside to this is that the rooms get noisy and make it harder to follow actual conversations between humans. One strategy we use to combat that is creating multiple rooms and focusing them around a subject. ...