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:
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