[chef-dev] Re: Re: Re: socket control for chef-client

[John Vincent < >]

(reposting again from the right email addy I think)



What exactly is the concern here? If you don't trust your client runs
to not undo something then you've got a much bigger problem.

If the concern is time, then better effort is spent optimizing the cookbooks.

Please also consider something like this:

https://gist.github.com/1979216

If you really need to ensure that something is a one time thing, add
it to the runlist for a run and make sure it cleans itself up
afterwards. You can even use the 'oneshot' cookbook that Matt Ray
wrote for something more data driven.

On Mon, Mar 5, 2012 at 11:34 AM,  
<
 >
 wrote:
> Joseph Holsten 
> <
 >
>  writes:
>
>> On Mar 5, 2012, at 5:33 AM, 
>> 
 
>>  wrote:
>>
>>> While I'm at it, have you had more thoughts about the idea behind
>>> https://github.com/grantr/chef/commits/socket ;?
>>>
>>> It provides a way to trigger single-recipe runs.
>>
>> Looks like it does a great deal more than that, it's basically a
>> first pass at an IPC API. You could build on this to push in any
>> config change you wanted (node attributes, log level, etc). Very
>> cool indeed.
>
>>
>> My question is: don't you want those changes written down somewhere?
>> What's the added value in applying a run list that isn't from a chef
>> server or solo repository? What extra good does it have over
>> updating the centralized run list and just running chef?
>
> In my case i just want to be able to run one recipe instead of the
> main huge centralised run_list.
>
> Again, I could work around this with a special cookbook that would
> alter the run_list.
> For example the special cookbook would read a json file (with either
> recipes to run, or recipes to skip), alter chef-client run_list
> accordingly and remove the json file eventually.
>
>
> --
> Laurent