November 20143
October 20143
September 20142
July 20141
March 20146
February 20141
January 20145
December 20135
November 20132
October 20134
August 20134
July 20132
Full Archives

Thu, 17 Mar 2011

Puppet Cucumber Providers

At work we try, and sometimes even succeed, in using Test Driven Deployment so as one of my background projects I've been wrapping certain tools in to cucumber friendly forms. Over the last couple of days I've been grabbing ten minutes here and there to incorporate Puppet 2.6 in to the pile.

Feature: Puppetwrappers
  Puppet Provider Examples

  Scenario: Confirming package installation
    When a machine has been puppeted
    Then the bash package should be installed

  Scenario: Confirm doodoodoo package is absent
    When a machine has been puppeted
    Then the doodoodoo package should not be installed

  Scenario: Confirm cron service is running
    When a machine has been puppeted
    Then the cron service should be running 

  Scenario: Confirm tomcat6 service is not running
    When a machine has been puppeted
    Then the tomcat6 service should not be running

  Scenario: Confirm dwilson is in libvirtd group
    When a machine has been puppeted
    Then dwilson should be a member of libvirtd

  Scenario: Confirm dwilson has a uid of 1000
    When a machine has been puppeted
    Then dwilson should have a uid of 1000

  Scenario: Confirm dwilson has a given shell
    When a machine has been puppeted
    Then dwilson should have the /bin/bash shell

I really like using the puppet providers for this because of the abstraction benefits they provide. I can write steps to test packages, services or aspects of a user and not have to worry if a developer runs it on Fedora or Debian.

This is only a first draft, and the cucumber wording needs changing, but I thought I'd put it online to show how expressive cucumber can be for system tasks and how easy, and concise, it is to reuse the puppet providers. You can grab the puppet step code and the Puppet providers features to drop in to your own test harnesses and have a play with. The implementation is pretty simple, for example the code below is everything you need for the service scenarios:

Then /^the (.+) service should be running$/ do | service |
  service_status = Puppet::Type.type(:service).new(:name => service, :hasstatus => true).provider.status
  service_status.should == :running

Then /^the (.+) service should not be running$/ do | service |
  service_status = Puppet::Type.type(:service).new(:name =>service).provider.status
  service_status.should == :stopped

It's worth mentioning that all the above will only work in 2.6 and above as the internal details returned by the providers are different to those in 2.5.

Posted: 2011/03/17 19:16 | /tools/puppet | Permanent link to this entry

OpenIndiana - LOSUG March 2011

Tonights (the March 2011) London OpenSolaris User Group (LOSUG) was a little different to usual and while the topics have always been quite diverse we've never had as seditious a talk as one covering the Solaris fork, OpenIndiana, Illumos and the OpenSolaris community.

Alasdair Lumsden did an excellent job of explaining the new projects, why they exist and what they're aiming for. As someone who took a few steps back when Oracle purchased Solaris it was an interesting catch up. The short version seems to be that "Illumos is a derivative of OS/Net (aka ON), which basically is a Solaris/OpenSolaris kernel with the bulk of the drivers, core libraries, and basic utilities." (from Wikipedia) and is being quite heavily invested in by companies (such as Joynet and Nexenta) and by individuals that were previous employed by Sun to work on Solaris. OpenIndiana is to become an OpenSolaris distribution and packaged software ecosystem.

To me the project has a similar feel to the early days of CentOS and Scientific Linux and I think my biggest take home is that Illumos and OpenIndiana, when taken together, want to be to Solaris what CentOS and Scientific Linux are to Red Hat Enterprise Server. Unfortunately they have a massive disadvantage as Solaris, unlike upstream Red Hat, isn't entirely open. One of the most immediately visible casualties is the excellent ZFS, which is closed source upstream and will both lag behind and diverge from the official Solaris version. Which I consider to be a great loss.

On a more cheerful note the OpenIndiana project is looking for people with an interest in taking free Solaris forward and is still young enough that there are plenty of interesting aspects to get involved with. Websites, CI environments (I'm guessing they won't use Hudson. Heh) and all the other usual roles a large opensource project needs filling are up for grabs.

The talk itself was quite well attended, with what looked to be 35-40 people in the audience, and well presented. It's also the first time I've been in to Oracles Moorgate offices and they're actually quite nice and modern. The open sided lift and the suspended spiral staircase that only serves three floors were personal highlights.

I wish the project well and hope it enjoys success while being able to retain some of what made Solaris great. I may even take the DVD for a spin...

Posted: 2011/03/17 00:03 | /events | Permanent link to this entry

books career cloud events firefox geekstuff linux meta misctech movies nottech perl programming security sites sysadmin tools tools/ansible tools/commandline tools/gui tools/network tools/online tools/puppet unixdaemon

Copyright © 2000-2014 Dean Wilson :: RSS Feed