Knife zero existing node discovery

Question

I'm getting acquainted with chef and want to build my workflow without central server (using chef-zero and knife zero). Everything works fine, however, chef-zero stores information about nodes in .json files that are rather big and changed too often to be stored in git repository, and i would like to rescan servers at each working day rather than store their definitions in repository - this should be easily automatable as we don't have many servers. Is there any command that would let me add existing converged nodes to chef-zero just by providing their ssh credentials? I know that knife zero bootstrap <node-ip> will do the trick, but it also triggers extra converge i don't want to happen.

Answer 1

The whole question was based around wrong assumptions:

• I thought chef node persists and manages it's own state. It is not. Node state is serialized at the end of chef-run and is passed to server, so it's not possible to re-discover node as i was attempting without a chef run. If you need server attributes, you may try to converge node with empty run-list; since run lists are not persisted on node itself, this should be safe operation.
• I also thought that chef-zero is somehow manages node state in other way than using json files. That was a result of me trying to directly specify node roles in json while they are constantly rebuilt from run_list, so i was confused seeing my roles not apply; that makes "discovery" i was talking about not necessary at all.

The following structure is sufficient for chef-zero to see the node and successfully converge it:

{
  "name": "sonarqube.srv.company.my",
  "automatic": {
    // automatic attributes are managed by ohai, so be ready that next 
    // chef run may use another fqdn if you haven't pinned it with 
    // any means possible
    "fqdn": "99-199-255-99.srv.company.my"
  },
  "run_list": [
     "role[role-1]"
     "recipe[cookbook::recipe]"
  ]
}

If you store definitions like that in git, you always have your infrastructure at hand and may do knife converge name:sonarqube.srv.company.my at any moment, and that beats all my needs. My personal workflow contains directory named managed-nodes with node specs like above that overwrites nodes directory on bin/reset included bash script. As long as i keep them stored with proper run lists and attributes, everything works like a charm. However, if you choose similar workflow, remember that you don't have to full attribute list without successful chef run on node.

The necessity of purely git-based chef workflow with no persistent server is dictated by some internal reasons i would like not to disclose. _{^{Ok, i just wanted idempotent ansible.}}

Kudos go to @Tensibai for all effort.

Answer 2

Just to be clear, you are basically describing making your own (bad) Chef Server. If you want centralized management you should probably just use Chef Server and save yourself some time :)