Here's a fork of adam's hoptoad handler which I've made work with chef 0.9.6.
(I think adam's code must have been for an older or newer version of chef.)
To install it place the chef-handler-hoptoad.rb file in /etc/chef, and then add
these two lines to client.rb
===================
require '/etc/chef/chef-handler-hoptoad'
exception_handlers << Chef::Handler::Hoptoad.new(:api_key=>XXX)
Hoptoad will now start emailing exceptions to you... e.g....
===================
Error Message:
Chef::Exceptions:
No version specified, and no candidate version available for munin-node
Where:
cl0#run
/usr/lib/ruby/gems/1.8/gems/chef-0.9.6/bin/../lib/chef/provider/package.rb, line 50
Request:
params:
action: run
controller: cl0
rails_root: /
url: "http://localhost/"
Session:
? !ruby/symbol data
: {}
Environment:
PATH: "/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/lib/ruby/gems/1.8/bin"
PWD: /etc/sv/chef-client
RAILS_ENV: production
Backtrace:
/usr/lib/ruby/gems/1.8/gems/chef-0.9.6/bin/../lib/chef/provider/package.rb:50:in action_install' /usr/lib/ruby/gems/1.8/gems/chef-0.9.6/bin/../lib/chef/runner.rb:50:in send'
/usr/lib/ruby/gems/1.8/gems/chef-0.9.6/bin/../lib/chef/runner.rb:50:in run_action' /usr/lib/ruby/gems/1.8/gems/chef-0.9.6/bin/../lib/chef/runner.rb:107:in converge'
...
--
John Merrells
http://johnmerrells.com
+1.415.244.5808
This is awesome. Any plans to publish the gem?
Dan DeLeo
On Thu, Jul 15, 2010 at 11:54 AM, John Merrells john@merrells.com wrote:
Here’s a fork of adam’s hoptoad handler which I’ve made work with chef 0.9.6.
(I think adam’s code must have been for an older or newer version of chef.)
http://github.com/merrells/chef-handler-hoptoad
To install it place the chef-handler-hoptoad.rb file in /etc/chef, and then add
these two lines to client.rb
===================
require '/etc/chef/chef-handler-hoptoad’
exception_handlers << Chef::Handler::Hoptoad.new(:api_key=>XXX)
Hoptoad will now start emailing exceptions to you… e.g…
===================
Error Message:
Chef::Exceptions:
No version specified, and no candidate version available for munin-node
Where:
cl0#run
/usr/lib/ruby/gems/1.8/gems/chef-0.9.6/bin/…/lib/chef/provider/package.rb, line 50
Request:
params:
action: run
controller: cl0
rails_root: /
url: “http://localhost/”
Session:
? !ruby/symbol data
: {}
Environment:
PATH: "/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/lib/ruby/gems/1.8/bin"
PWD: /etc/sv/chef-client
RAILS_ENV: production
Backtrace:
/usr/lib/ruby/gems/1.8/gems/chef-0.9.6/bin/…/lib/chef/provider/package.rb:50:in action_install' /usr/lib/ruby/gems/1.8/gems/chef-0.9.6/bin/../lib/chef/runner.rb:50:insend’
/usr/lib/ruby/gems/1.8/gems/chef-0.9.6/bin/…/lib/chef/runner.rb:50:in run_action' /usr/lib/ruby/gems/1.8/gems/chef-0.9.6/bin/../lib/chef/runner.rb:107:inconverge’
…
–
John Merrells
http://johnmerrells.com
+1.415.244.5808
On Jul 15, 2010, at 11:58 AM, Daniel DeLeo wrote:
This is awesome. Any plans to publish the gem?
I don’t think it really warrants being a gem. I think it should be added to the 'chef::client’
cookbook recipe… then the user could select the notifier(s) they want enabled via the
cookbook attributes.
On a related topic… I still don’t quite grok how one can contribute back to the cookbooks…
there are multiple repos of cookbooks… and multiple repos of single cookbooks… so its
kinda hard to contribute.
So far I’ve found the existing cookbooks to be a very useful crib for writing my own… often
I copy one, hack away the stuff I’m not interested in (apache, etc) and then add the few
small twiddles I need (e.g. nginx).
Also, I tend to work on a recipe until it works for me… and then stop working on it… and
I don’t bother making it generic enough for anybody to use… me being lazy but I think
the contributing back hurdle is too high.
John
–
John Merrells
http://johnmerrells.com
+1.415.244.5808
I agree on the hurdle to contribute. My hurdle is how can I maintain a ‘dev’ environment and a clean gem installed environment for ‘normal’ work. Like John, I’m short on time, so the hurdle to ‘easy’ contributions just keeps me pigeon-holed working on my own stuff.
Another thing is I’d publish my chef repo on github, but it’s problematic because I have some stuff in there I don’t want published, keys, passwords, etc.
I’d love to read how some of the opscode guys are doing chef dev work AND working on maintaining systems with chef, what their workflow is, etc.
Alex
On Jul 15, 2010, at 12:47 PM, John Merrells wrote:
On Jul 15, 2010, at 11:58 AM, Daniel DeLeo wrote:
This is awesome. Any plans to publish the gem?
I don’t think it really warrants being a gem. I think it should be added to the 'chef::client’
cookbook recipe… then the user could select the notifier(s) they want enabled via the
cookbook attributes.
On a related topic… I still don’t quite grok how one can contribute back to the cookbooks…
there are multiple repos of cookbooks… and multiple repos of single cookbooks… so its
kinda hard to contribute.
So far I’ve found the existing cookbooks to be a very useful crib for writing my own… often
I copy one, hack away the stuff I’m not interested in (apache, etc) and then add the few
small twiddles I need (e.g. nginx).
Also, I tend to work on a recipe until it works for me… and then stop working on it… and
I don’t bother making it generic enough for anybody to use… me being lazy but I think
the contributing back hurdle is too high.
John
–
John Merrells
http://johnmerrells.com
+1.415.244.5808
Ohai!
On Jul 15, 2010, at 2:40 PM, Alex Soto wrote:
I’d love to read how some of the opscode guys are doing chef dev work AND working on maintaining systems with chef, what their workflow is, etc.
We have a number of repositories. First, the two open source ones we start with:
- Cookbooks http://github.com/opscode/cookbooks
- Chef Repository http://github.com/opscode/chef-repo
I actually maintain both of these repositories for Opscode, and they are separate from my own testing repositories.
I work with a number of Chef Servers for testing cookbooks, doing development workflow and building our training material, etc. Each of these servers has a corresponding chef-repo, and each one has a different Opscode Platform organization as the Chef Server (except the case of my local OSS Chef Server for testing installation).
I first clone the chef-repo, then I use the vendor branch workflow described on our help site0. Most of these repos are private or throwaway. If they were something I wanted to publish to a central repo, then that would have either the apprpriate github repository (private or public depending on the use), or a private internal Git server.
I hope this helps clarify, along with the contributing email I sent to the list a few minutes ago. If not, let me know if you have further questions.
–
Opscode, Inc
Joshua Timberman, Senior Solutions Engineer
C: 720.334.RUBY E: joshua@opscode.com