[chef] Re: Re: Actions taken when adding new nodes

[Zac Stevens < >]

On Thu, Aug 25, 2011 at 5:09 PM, Brian Akins 
<
 >
 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