infochimps-labs/ironfan — Issue #109: knife cluster kick shouldn't rely on already running chef-client
Author: dhruvbansal
Created: 2012-02-28 19:44:05+00:00
State: open

Currently, running `knife cluster kick` will cause an existing `chef-client` process on a node to start executing. I propose that we have `knife cluster kick` instead launch a *new* `chef-client` process, just like running `sudo chef-client` manually on the node would do.

This would fix several problems associated with long-running `chef-client` processes:

1) Cookbooks sometimes install gems during the compile phase that they need during the execution phase. If gem 'foo' is being installed at version '2.1.0' but the long-running `chef-client` has already loaded version '2.0.0' from a previous run, then we're in a bad state.

2) Database and service handles created in one run may be reused in another run, later, instead of being refreshed. This burden is placed upon the cookbook's author and many authors will not deal with the issue of handles becoming stale and needing to be reset, instead using them directly if they're available.

In both cases, insisting on utilizing a long-running `chef-client` process introduces complexity downstream for cookbook authors while a "fresh" run would immediately solve both.

What would we **lose** by making `knife cluster kick` launch a fresh `chef-client` as opposed to kicking an existing one?