search

chef-boneyard / chef-provisioning

A library for creating machines and infrastructures idempotently in Chef.
Apache License 2.0
524 stars 164 forks source link

Don't continually manage `client.rb`. #318

Open dblessing opened 9 years ago

dblessing commented 9 years ago

Chef provisioning should lay down client.rb only once. The issue we're running in to is Provisioning comes along and creates client.rb then does the first converge which runs our recipes to configure chef-client further, including add other options to client.rb. Then we run into a scenario where Provisioning and the chef client daemon fight over the configuration continually changing it back and forth between what Provisioning and the daemon want. I think Chef Provisioning should only manage this file once and then leave it to the node's recipes to determine.

jtimberman commented 9 years ago

You're using the chef-client cookbook or otherwise managing client.rb in a recipe?

I am in favor of this too :).

dblessing commented 9 years ago

Yep, exactly :)

lynchc commented 9 years ago

+1

jkeiser commented 9 years ago

From the PR: we'd like to not do this globally; but it would be good to get a toggle in, at the least (and turn it on by default if your machine has the chef-client cookbook in the run list).

tyler-ball commented 9 years ago

Moving my notes from https://github.com/chef/chef-provisioning/pull/382#issuecomment-130072251 to here

Pinging this for feedback on the following 2 issues:

I think a better way would be to inspect the chef server and determine if there is already a client object for the node in question. What do you think of that?

I also think that the converge_if_missing action is the best way to make it configurable. That way users can still use the converge action if they want to force convergence.

There is also the converge attribute that we could modify. We could make it accept a symbol instead of true/false. Then users could provide :always, :if_missing or :never. Then true/false could be cast to :always/:never.