[chef] Re: chef-provisioning / knife-zero


Chronological Thread 
  • From: Mark Harrison < >
  • To:
  • Subject: [chef] Re: chef-provisioning / knife-zero
  • Date: Fri, 29 May 2015 13:45:17 -0400

As I understand it (and one of the creators/maintainers of chef-provisioning please step in and correct me if I'm wrong) chef-provisioning's intended use is for the initial bootstrapping of the machine, and it would 'replace' commands like knife ec2 server create. The initial converge when creating the machine would then use something like the chef-client cookbook to set up chef client against the chef server and you would use daemonized/cronned/manual chef client runs on the server itself against the chef server. After the initial bootstrap is complete, chef-provisioning itself would never run a converge unless the machine needed to be recreated.

Obviously this is a little different than your use case, and it sounds similar to something I have done at mivok.net/2015/05/19/chef-provisioning-ssh.html. However, in the examples there, I have just set 'converge true' in the machine definition to run a chef converge every time on all machines, and ignored the problem of what to do if you only want to converge one machine.

I suspect your idea of using environment variables, or providing json attributes on the command line with something like "chef-client -z -j <(echo '{"converge_node": "mynode"}')", is the way to go for now. Compare that value with the current node name and add 'converge true' to the machine definition if it matches. The other nodes won't converge (but chef provisioning will make sure they exist).

On Fri, May 29, 2015 at 6:03 AM, Roland Moriz < " target="_blank"> > wrote:
Hi everyone!

I'm currently maintaining a couple of small (<25 nodes) knife-solo[1] and knife-zero[2] setups.

Typically the setups are too small to run a traditional chef-server setup, also the owners don't want to rely on third party services (data protection, latency) - so hosted chef is not a solution.

Recently I've re-evaluated the current state of chef-provisioning and it looks way better than a couple of months ago. However I'm not sure how this is meant to replace the "knife-*" solutions out there: While setting up a couple of machines with attributes/run-list is very nice using the Chef-Provisioning Chef-DSL, my customers usually don't want to (re-)converge *all* nodes but run chef-client explicitly on one (or more) nodes.

Example provisioning recipe: https://gist.github.com/rmoriz/f293ca1402591c5469ae

I can run "bundle exec chef-client -z provisioning/test.rb" and the instances will be provisioned, bootstrapped and converged. awesome!
But how do I later use chef-zero to converge e.g. *only* the nginx node? When I re-run the recipe, all nodes will be converged.

As far as I understand, I could add some attributes or even (ab)use local environment variables to execute only specific resources of the chef-provisinioning cookbook, but I'm sure this is not the right way to do it, right?

A "one node per recipe"-approach seems to be very non-DRY to me and breaks all the nice "10.times do |i| … end" examples to create a bunch of identical nodes.

I'm missing something like knife-zero in the mix, unfortunately it currently use a different port for knife-zero forwarding which currently makes it incompatible.

Any hints? Thanks :)

best regards
Roland

[1] https://github.com/matschaffer/knife-solo
[2] https://github.com/higanworks/knife-zero




Archive powered by MHonArc 2.6.16.

§