I see that Chef has a feature where a node recipe can take actions based on
searching, for example, for all existing nodes that have a particular role, say
XX. If a node with role XX is then added or removed, the value of the search
will then be different. Is there some mechanism that will cause the code that
did the search to be run again? If so, what is the mechanism and are there any
potential pitfalls when using it?
I'm new to chef myself, so I hope I have this right... 
If your recipe uses a search function, that search function is executed every time the recipe is run, thus whenever chef-client is executed on the node, the template using the search results will be updated.
Example: when using Amazon EC2, you have 2 instances with role "webserver" and once instance with role "load balancer" running HAProxy. Since ec2 instances are all referenced by dns names, and they can change, the HAproxy config uses a search function to find the internal DNS names for any nodes with role "webserver" and adds them to its loadbalancing pool.
Chef-client on the haproxy instance is configured to run in daemon mode every 30 minutes (or via cron every 30 minutes), so if one of the webserver instances dies, and respawns with a new internal dns address, within 30 minutes the haproxy config will be updated with the new address because the search is executed again.
On Aug 25, 2011, at 8:30 AM, david.kranz@qrclab.com wrote:
I see that Chef has a feature where a node recipe can take actions based on
searching, for example, for all existing nodes that have a particular role, say
XX. If a node with role XX is then added or removed, the value of the search
will then be different. Is there some mechanism that will cause the code that
did the search to be run again? If so, what is the mechanism and are there any
potential pitfalls when using it?
Not currently. I think some of the Chef + Noah hacking may would solve
this. We played with a mechanism, but never finished it. In our never
finished prototype, a node would use a “special” search that registered that
node as caring about those results. Something would keep track of those
results and notify the registered nodes. We played with it as an HTTP
service with polling, but wanted to try it in Noah, then we got busy with
other things.
On Thu, Aug 25, 2011 at 5:09 PM, Brian Akins brian@akins.org wrote:
Not currently. I think some of the Chef + Noah hacking may would solve
this. We played with a mechanism, but never finished it. In our never
finished prototype, a node would use a "special" search that registered that
node as caring about those results. Something would keep track of those
results and notify the registered nodes. We played with it as an HTTP
service with polling, but wanted to try it in Noah, then we got busy with
other things.
That sounds pretty cool.
I've got an unfinished prototype using MCollective that comes at this
problem from the other direction. The basic shape of things involves
an agent which can kick off a Chef run (I don't the client's daemon
mode), and an LWRP which makes the agent call.
Usage looks something like this:
service "apache2" do
service_name "httpd"
action [ :enable, :start ]
notifies :send, "mco_notify[restart_loadbalancers]"
end
mco_notify "restart_loadbalancers" do
rpc_agent "chef"
rpc_action "run_once"
nodes_with_class "role.loadbalancer"
action :nothing
end
There are numerous problems with the naive approach in this prototype,
and I don't plan to use it in production, but I'll put it online as an
example if there's interest. In particular, the RPC approach means
that 100 reconfigured webservers (in this example) will each make its
own attempt to reconfigure the load balancers. It's also necessary to
save the node state before sending the reconfigure request, if the
target node(s) require visibility of the new state on the client node.
I don't have strong feelings about which direction the relationship
should be defined - webservers notifying loadbalancers of changes, vs
loadbalancers subscribing to changes of webservers. Some use cases
will be more clearly expressed one way or the other, but I suspect
both approaches have value.
Zac