However, Chef is not yet able to use this packaging system as it does not have a PkgNG provider, or not had. This is a hacky way to do so but here is a way to use PkgNG with chef, making it the default provider for your packages.

require 'chef/mixin/shell_out'
require 'chef/platform'
require 'chef'
 
include Chef::Mixin::ShellOut
 
class Chef
  class Provider
    class Package
      class Pkgng < Chef::Provider::Package
 
        def initialize(*args)
          super
          @current_resource = Chef::Resource::Package.new(@new_resource.name)
          @current_resource.package_name(@new_resource.package_name)
          @current_resource
        end
 
        def check_package_state
          pkg_info = shell_out!("pkg info #{package_name}", :env => nil, :returns => [0,70])
 
          version = nil
          t = pkg_info.stdout.match(/(.*)-(\d+\.\d+\.\d+(\.\d+.*\s)?)\s+(.*)/)
          unless t.nil?
            version = t[2].strip
          end
 
          return version
        end
 
        def load_current_resource
           @current_resource.package_name(@new_resource.package_name)
           @current_resource.version(self.check_package_state())
           @candidate_version = ""
        end
 
        def package_name
          @new_resource.package_name
        end
 
        def install_package(name, version = "")
          shell_out!("pkg install -y #{package_name}", :env => nil).status
          Chef::Log.debug("PKGNG : #{@new_resource} installed from: #{@new_resource.source}")
        end
 
        def remove_package(name, version = nil)
            shell_out!("pkg delete -y #{package_name}", :env => nil).status
        end
      end
    end
  end
end

Chef::Platform.set({
  :platform => :freebsd,
  :resource => :package,
  :provider => Chef::Provider::Package::Pkgng
})

Read more : poudriere & pkgng

First, the asynchronous handler has been updated, pushing backing data a bit differently and fixing a stupid issue on diffs. Check it out, it is needed for this new version of the cuisine dashboard.

I added a consumer that allows to use postgresql as storage backend. This does NOT replace the need for elasticsearch. It’s by making mistakes that you learn, and this one was pretty insightful : it’s better (necessary ?) to have a permanent storage you can rely on. When you come to update mappings, change stuff everywhere you don’t want to loose your data, so reindexing is the solution. There are now 3 scripts to cope with the incoming data :

• direct indexing to ES, this one does NOT remove data from message queue.
• storing to PG, data is removed from message queue
• going to both, data is removed from message queue

These scripts will probably be federated to a single one later, that will be a proper daemon (with logging, pid files and such)

UPDATE : this rewrite is done. A single script allows data consumption, indexing and storage. As a bonus, a quick and dirty packager based on FPM is provided.

In the additions, cuisine now takes enviroments in account, you can filter when looking the last runs and in search you can restrict to a particular one.

To end this post, a few screenshots :

The changes (including diffs) are pushed in a queue. This queue is consumed by a script and datas are indexed in elasticsearch, an open source search engine. On the top of this I wrote a web interface, based on sinatra and twitter’s bootstrap) that allow you to see the latest runs, filter out runs with no changes and search on criterias (hostname, updated resources and inside the diffs)

To use this you will need a couple of things :

• a STOMP broker (I use rabbitmq, but activemq or stompserver will fit too)
• an elasticsearch instance (or cluster)
• sinatra and its dependencies + the stomp ruby gem

The code is available on github, feel free to get in touch on freenode IRC, you can find me on the #chef-hacking channel (nickname : nico)

I’ve put that on my github chef repo, check the readme for the extensive file list & function.

mco rpc chef runonce or  mco rpc chef status
The plugin is available on my github mcollective repository.

The mandatory internet meme reference : yes xzibit approves.

So, this is a generic chef resource mcollective agent, with the associated example client code. It anyway deserves an little explanation; it is not mean to work with a command line invocation. Why ? Because I push quite “complex” data as the resourceactions parameter. The only way I found to make this work from command line is to use eval on the argument, which is no way acceptable. Anyway I hope some people will find this useful.

However, a tool I still have is the awesome mcollective. Unfortunately, the most used agents (package, service) relay on puppet providers to do their actions. Fortunately, open source is here, so I wrote a (basic) service agent that uses chef providers to start/stop or restart an agent. It still needs some polish for the status part (ho the ugly hardcoded path) but I was quite excited to share this. Freshly pushed on github !

Thanks to Jordan Sissel for minstrel, an awesome debug tool, the opscode team for the help on the provider and R.I. Pienaar for mcollective (and the support).

mc-cluster-ssh --wf kernel=OpenBSD

Grab it in my github

This has been possible with the help of @ripienaar. Thanks for the explanation for the difference between topics & queues !