I’m wondering if it’s possible to force the Chef client to run on a
node from an API call?
I’m building a fairly large configuration file using data from a
databag. The databag is updated by a client-facing external application
using the Chef server API, at which point I’d ideally like to force a
chef-client run in order to rebuild the configuration on the server. The
reason for this is primarily to keep end-users happy, as I’m not sure
they would be happy making a configuration change and having to wait 30
minutes for the next convergence. FWIW I’m using the chef-client
cookbook.
I know this can be done using knife ssh, but I was hoping for
something built-in that can handle this via a RESTful API call.
If nothing exists I’ll write some kind of wrapper around knife ssh, but
doing things like that always feels wrong to me! (Probably because I’m
trying to make Chef do something it wasn’t designed for
On Mon, Jan 7, 2013 at 10:30 AM, Dane Elwell mlist@xiol.co.uk wrote:
I know this can be done using knife ssh, but I was hoping for something
built-in that can handle this via a RESTful API call.
There is nothing that I know of. We use a combination of SSH and winrm to
kickstart our converges after updating the central server.
As most of our releases end up requiring multi-node coordination we tend to
break releases into stages, then interleave updating of the central server
with ssh/winrm calls out to the client nodes, testing the resultant
converged and state and moving on to next stage in release.
theres nothing out of the box. chef is pull only, the clients asks for
recipes from the server, a server in itself can not enforce/dispatch a
client run. you can use knife-ssh, ansible or mcollective for this.
On Mon, Jan 7, 2013 at 10:30 AM, Dane Elwell mlist@xiol.co.uk wrote:
I know this can be done using knife ssh, but I was hoping for something
built-in that can handle this via a RESTful API call.
There is nothing that I know of. We use a combination of SSH and winrm to
kickstart our converges after updating the central server.
As most of our releases end up requiring multi-node coordination we tend
to break releases into stages, then interleave updating of the central
server with ssh/winrm calls out to the client nodes, testing the resultant
converged and state and moving on to next stage in release.
