[chef] Re: Re: Ad-hoc tasks and ad-hoc sources

[Alon Rohter < >]

I'm actually quite interested in ad hoc resource execution as well, particularly as applied to more advanced orchestration uses.  For command and control, full chef-client runs are expensive and awkward, particularly when I need to run one-off resources/recipes.  I love having all my code in one place, and utilizing all the existing knowledge/state that the chef-server keeps about my infrastructure, so having to use some external system (like mcollective) to handle this kind of thing isn't appealing.

I'd love to hear what others have come up with / hacked together.  I've started investigating using RightLink ( https://github.com/rightscale/right_link ) and particularly its RemoteRecipe feature (without using RightScale's saas platform).  I'm also considering writing my own (much simpler) message command --> recipe execution layer, but I still need a decent way to execute arbitrary Recipes/Resources on a node without mucking about with run_list hacks.

-a

On Tue, Mar 6, 2012 at 1:44 AM, Denis Barishev < "> > wrote:

On 03/02/2012 08:50 AM, Three Tee wrote:

Are there any best practices that have emerged around executing ad-hoc tasks via Chef? A use case that seems to come up often for me is performing code deployments using the application cookbook without executing any other configuration tasks that would usually be executed by the run_list. I understand that with Chef one typically considers a deployment to be inclusive of the prerequisite package installations, etc., but humor me for a bit. :)

Anyway, a couple of ways that I thought the above might be handled are to either set the run_list on the fly prior to the chef-client run, or to execute chef-client on the target nodes with the -j option, passing it an ad hoc run_list in the JSON. The former would require the previous run_list to be saved, then restored after the chef-client run (assuming it is successful). The latter appears to set the run_list on the Chef server after the chef-client run. Both options seem to make it difficult to use the nodes' run_list settings on the Chef server as a source of truth for a node's function, so I'm not really happy with either one.

I'd love to hear how you all have handled the above problem. Or maybe I'm just looking at this the wrong way? In any case, thanks in advance for any advice.

Also on this topic, I noticed the following on http://wiki.opscode.com/display/chef/FAQ:
"...by making Chef's Resources capable of taking action from ad-hoc sources. (This isn't released yet, but it will be soon - and trust us, it is awesome.)"

The above seems promising for the use case I described, and is interesting in general. Can anyone provide any more detail on this? Thanks everyone!

Hi, I prefer not save node data at all to saving/restoring run_list. If you like you can easily achieve this by this simple code:

class Chef::Client
  def save_updated_node
  end
end

Regards,
Denis