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

["Wagner, Jason" < >]

The "IPC" aspect would be extremely useful for "push" notifications rather than "polling" of changes to the cluster. This would enable notify/subscribe between nodes, not just within a node, correct?

That would let a node trigger immediate converges on another node in a data-driven manner. For example, I have an Apache reverse proxy that listens for services that announce that they wish to be made available as part of a dashboard. It queries all nodes that provide a dashboard widget, similar to what Infochimp's Silverware does.  

When bringing up the cluster or adding something, I have to manually trigger the converge on the Apache node, if I understand Chef correctly. This gives the dashboard widget recipe the opportunity to announce that the Dashboard provider node needs to reconverge to pick up a new node. See the Silverware cookbook from Infochimps.

Or am I missing something that Chef already does?

On Mon, Mar 5, 2012 at 10:31 AM, Joseph Holsten < "> > wrote:

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?

--
http://josephholsten.com

-- 
Jason Wagner

" target="_blank">