chef_knives: chef addons to become a cooking master!


#1

Hey guys!

Just a quick email to say thank-you!

We are evaluating Chef in a 200+ nodes infrastructure. We’re loving it!

I’ve created a little github repo with some scripts we use internally
to gather info from the CouchDB chef database.

Documentation:

Keep on rocking guys,

we
need
Chef!

Cheers!
Sergio.


#2

Nice work, Sergio!

We haven’t done much work yet on the reporting potential of Chef, so
it’s great to see what you’ve done. I think it would be cool to see
this evolve into a big collection… :slight_smile:

Just to make sure we don’t stomp on each other, Chef 0.8 will ship
with an expanded version of corp’s ‘knife’ command line utility.

Let us know if there is anything we can to do help,
Adam

On Fri, Sep 11, 2009 at 3:27 AM, Sergio Rubio rubiojr.ml@gmail.com wrote:

Hey guys!

Just a quick email to say thank-you!

We are evaluating Chef in a 200+ nodes infrastructure. We’re loving it!

I’ve created a little github repo with some scripts we use internally
to gather info from the CouchDB chef database.

http://github.com/rubiojr/chef-knives

Documentation:
http://wiki.github.com/rubiojr/chef-knives

Keep on rocking guys,

we
need
Chef!

Cheers!
Sergio.


Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com


#3

Hey Adam!

On Fri, Sep 11, 2009 at 8:05 PM, Adam Jacob adam@opscode.com wrote:

Nice work, Sergio!

Thanks!

We haven’t done much work yet on the reporting potential of Chef, so
it’s great to see what you’ve done. I think it would be cool to see
this evolve into a big collection… :slight_smile:

We are trying to add a chef backend to our datacenter inventory app.
I’ll let you know how it goes… :D. From what I can see, node
attributes from ohai are everything we need (almost)

Just to make sure we don’t stomp on each other, Chef 0.8 will ship
with an expanded version of corp’s ‘knife’ command line utility.

Not quite sure what you mean. Do you mean naming a chef_knives script
knife? No worries if that’s the case!

Let us know if there is anything we can to do help,
Adam

Sure! in fact (:D) we are writing some ohai plugins, but we haven’t
found the documented way of installing them so we use the following
method:

  1. edit /etc/chef/client.rb
  2. add the following line to the end of the file:

Ohai::Config[:plugin_path] << ‘/etc/ohai/plugins’ #you can choose
any path you want

  1. add your custom plugins there (i.e. /etc/ohai/plugins)
  2. reload the client:
    /etc/init.d/chef-client restart

Is there a better way of doing it?
What happens if a future/new version of an ohai plugin overrides or
uses the same name for an attribute that we are using in a custom
plugin? (we put every attribute from our plugins under an attribute
with our company’s name to avoid this… hopefully that will be
enough…)

Let me know what you think.

One last thing. I’ve created a github repo with ohai plugins we are
writing, in case anyone is interested:

Cheers!


#4

On Wed, Sep 16, 2009 at 5:16 PM, Sergio Rubio rubiojr.ml@gmail.com wrote:

We are trying to add a chef backend to our datacenter inventory app.
I’ll let you know how it goes… :D. From what I can see, node
attributes from ohai are everything we need (almost)

Sounds interesting… We’re currently using GLPI :’( but we have
heavily customised it to produce rack diagrams etc… which is nice

The Ohai stuff could be an excellent addition to the inventory part of
new provisions


$ echo “kpfmAdpoofdufevq/dp/vl” | perl -pe ‘s/(.)/chr(ord($1)-1)/ge’


#5

Sergio, this is pretty cool stuff, I’ll definitely be keeping an eye on it
and playing with it some more in the next few days. The data in chef has
huge potential, it’s nice to see some people working to unlock it.
Just to clear up the “knife” thing, knife is a command line program that
works with the chef HTTP API. You can see the proof-of-concept version here:

So when 0.8 is released, (to my knowledge) installing it will also install
the knife program (much improved from the gist version) in your rubygems bin
directory (or some bin directory depending on the install method).

Dan DeLeo

On Wed, Sep 16, 2009 at 10:16 AM, Sergio Rubio rubiojr.ml@gmail.com wrote:

Hey Adam!

On Fri, Sep 11, 2009 at 8:05 PM, Adam Jacob adam@opscode.com wrote:

Nice work, Sergio!

Thanks!

We haven’t done much work yet on the reporting potential of Chef, so
it’s great to see what you’ve done. I think it would be cool to see
this evolve into a big collection… :slight_smile:

We are trying to add a chef backend to our datacenter inventory app.
I’ll let you know how it goes… :D. From what I can see, node
attributes from ohai are everything we need (almost)

Just to make sure we don’t stomp on each other, Chef 0.8 will ship
with an expanded version of corp’s ‘knife’ command line utility.

Not quite sure what you mean. Do you mean naming a chef_knives script
knife? No worries if that’s the case!

Let us know if there is anything we can to do help,
Adam

Sure! in fact (:D) we are writing some ohai plugins, but we haven’t
found the documented way of installing them so we use the following
method:

  1. edit /etc/chef/client.rb
  2. add the following line to the end of the file:

Ohai::Config[:plugin_path] << ‘/etc/ohai/plugins’ #you can choose
any path you want

  1. add your custom plugins there (i.e. /etc/ohai/plugins)
  2. reload the client:
    /etc/init.d/chef-client restart

Is there a better way of doing it?
What happens if a future/new version of an ohai plugin overrides or
uses the same name for an attribute that we are using in a custom
plugin? (we put every attribute from our plugins under an attribute
with our company’s name to avoid this… hopefully that will be
enough…)

Let me know what you think.

One last thing. I’ve created a github repo with ohai plugins we are
writing, in case anyone is interested:

http://github.com/rubiojr/ohai-plugins

Cheers!