Posts Tagged ‘facter’

Getting Help for Puppet and Facter

November 7th, 2009

I just thought I’d mention some of the places you can get help with Puppet and Facter.

The first is the Puppet users mailing list (and for development related questions – the puppet-dev list too)

Also available is the #puppet IRC channel on Freenode where a lot of helpful people lurk and can answer questions (needless to say a lot of really interesting sysadmin related rant^H^H^H discussion also takes places there too).  Feel free to join and jump right in with a question and if you’re pasting in configuration or log output don’t forget to use the pastie bot or link to a pastie of your data.

For the documentation you can find it at the Wiki (we’re working on a new one – really, we are…).

Some useful links are the Configuration and Type References and the Language Tutorial.

Finally, if you’ve got a bug or an error message or you’re just stuck and can’t find help in some of the places I’ve just mentioned then we’d love it if you would log a ticket at the Reductive Labs Redmine site:

Specifically you can log issues for Puppet or Facter.

Please remember to include the Puppet (or Facter) version you are using (select it from the Affected Version drop-down), your platform and any log or trace output you have.  We recommend running your master and client with the –verbose –trace –debug options to get the most possible data out before logging the ticket.  That’ll help us resolve your issue.

And obviously I’d be remiss if I didn’t mention (disclaimer – I don’t work for Reductive Labs but Luke buys me drinks and I’d like him to be able to continue to do that) that Reductive does sell support for Puppet.

Hope that helps someone!

Hudson and Amazon EC2

June 8th, 2009

So my biggest gripe with Hudson is slave nodes. In Puppet land we need to run our tests on a wide variety of platforms – it’s a system/configuration management tool that runs on just about every flavour of *nix (and soon to be Windows) around: Linux (a bucket load of distros), *BSD, OSX, AIX, Solaris, HP-UX, amongst others. We need to ensure it builds, runs and configures things on these platforms and that new features and functions don’t break things. To do this there is a huge management overhead – especially as build/test is generally two or three people – mostly Luke and I.

In this process I’ve had many struggles with getting people to submit slaves and with managing my own slave node network for Hudson. It’s bloody annoying to have to fight RUBYLIB issues, Gem versions, installed versions of Puppet and Facter and a dozen other issues with running tests on slaves before you can even identify and fix a failed test.

I finally threw in the towel and decided to look at some other CI engines – perhaps my initial look and selection of Hudson had been premature.  But another review and installation of a wide variety of tools suggested to me that Hudson was the right choice. So an impasse.

Then along came the Hudson Amazon EC2 plug-in.  It allows Hudson to run up Amazon EC2 instances when required as slaves.  This means with a few judicious choices of AMIs I can quickly run up a test farm that covers all my requirements – Linux, Solaris, even Windows when we merge in the new Windows code (0.25.0beta2 I hope).  It’s not quite working yet – for reasons that aren’t 100% clear to me yet. :)   But it’s on the right path and I hope it’s going to make life much easier.  More on how it all works … when it all works..

UPDATE:  It now works – mostly a PEBCAK issue – the plug-in requires that the EC2 Security Group is configured to allow a connection on port 22 from the Hudson master.  Next steps some proper implementation… :P