infochimps/cluster_chef — Issue #90: Creating chef client at launch causes chaos. Not creating chef client at launch causes chaos.
Author: mrflip
Created: 2011-12-22 04:34:23+00:00
State: open

I don't know how to fix this. Here's what I know:

* There's currently no API for setting ACLs (permissions) on a chef node. The only way an api_client can have write access to a node is:
- if an admin client grants it access using the opscode dashboard
- a non-admin client is allowed to create a node with the same name - it then has write access to that client.
* So: if you want automation then your client must create the node.
* cluster_chef's orchestration capability depends on being able to manipulate the node directly
* So: if you want orchestration then the node must be created on the desktop of the person launching the cluster

So: the computer of the person launching the machine must also create the client.

____________

* A client key (let's call it "bob") is only good for two things:
- creating the node "bob".
- running chef-client on the machine corresponding to node "bob".
* The client key must ultimately become present on the machine itself.
* The default opscode-provided bootstrap scripts
- send the validation_key to the machine 'bob', who
- creates its own client with that key, dropping it into a file that now exists nowhere else in the world but that machine,
- meaning the client is useless if the machine is dead.

So: unless you modify your bootstrap scripts, the compluter of the person launching the machine must NOT also create the client -- only the machine itself can create the client.

* So you must run modified bootstrap scripts, eg https://github.com/infochimps/cluster_chef/blob/version_3/lib/chef/knife/bootstrap/ubuntu11.10-cluster_chef.erb

___________

* If @temujin9 launches a node (and thus also creates a client), the client key lands on his computer.
* Suppose he shuts down that machine, and I later want to launch a new instance.
* If the client exists, then I must _also_ have the client key on my computer.
* Which means that client keys are running around on everyone's computers, which is Not Good
* and would also mean that we have to be careful to push client keys back into the repo, which people will forget to do in the heat of battle.
* So instead, we require that the client ALWAYS lives or dies with the node.
- That's OK: hooray opinionated software; we already lived in a world where the client lived or dies with the machine...
- and if you always use cluster_chef, cluster_chef will ensure these remain consistent
- but it's easy to screw up if you're doing stuff outside cluster chef, and your punishment is both confusing and long in coming.
- (note that this means the client_key can/should be deleted after successful launch)

So in the current world where

* we want to create a node from the knife side
* client-node permissions are fucked

it unfortunately seems to be the case that

* you must use a bootstrap script (or client.rb) that delivers the client key onto the node
* you must ensure that clients live or die with their node.

_note_: this fucked situation is different from #62 -- that isssue is fixed by the working-well-but-necessarily-brittle code to ensure nodes and clients share the same lifecycle