[chef] Re: Re: Re: chef_knives: chef addons to become a cooking master!

[Daniel DeLeo < >]

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:

http://gist.github.com/100837

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 < "> > 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... :)
>

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

3. add your custom plugins there (i.e. /etc/ohai/plugins)
4. 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!