On Mar 21, 2012, at 11:49 AM, Alon Rohter wrote: 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.
The forked branch in question adds 3 run list modifiers that could help accomplish they type of partial chef runs you seem to be looking for.
Partial run list support is a contentious thing and there's definite valid points on both sides as to whether or not it's really a good approach, it's up to you to decide if the risks are worth it for your infrastructure.
-sean
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
|