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.

for those who may discover `--no-converge` option: sadly, this doesn't save node definition — Etki, Nov 07 '16 at 09:26
Avoiding the converge goes against the chef's philosophy of idempotence (run multiple times, act only when needed). So no there's no way with Chef to achieve what you wish, rethink your requirements/cookbooks thinking in about desired state and you'll don't care running chef multiple times (as any other SCM) — Tensibai, Nov 07 '16 at 12:42
@Tensibai while idempotence is truly one of key chef's aspects, it's surely unnecessary to fetch node state and register it. — Etki, Nov 07 '16 at 14:00
are you after `--audit-mode` then ? (I'm mainly talking about your "don't want an extra converge" which sounds like it may break you node state, where it should not) — Tensibai, Nov 07 '16 at 14:06
@Tensibai i was terribly sleepy yesterday, and my last sentence was ambiguous. I truly want to avoid converge simply because it's time-consuming task, not because i'm afraid to break things; my final goal is to restore `nodes` folder for chef-zero with as less effort as possible, because it seems that it is unnecessary to drag it inside repository everywhere. It seems that converge task actually does what i need to, but it, again, consumes time and i want to speed things up. Regular chef tasks like audit and converge *may* give desired output, but not directly what i'm after. — Etki, Nov 07 '16 at 22:27
I start to really wonder why you want to use chef zero and not a chef server then. You can still 'push' the local repo to a git server at end of converge. If you're after the automatic attributes only, you can run ohai by itself. I'm sorry but I really can't see a viable use case so I'm unable to help more, give a try asking http://discourse.chef.io some chef Inc folks may know a way (or maybe a special recipe made for failing after saving the node at end of compile time, but that sounds brittle and dangerous) — Tensibai, Nov 07 '16 at 22:53

score 0 · Answer 1 · answered Nov 09 '16 at 02:05

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.

score 0 · Answer 2 · answered Nov 18 '16 at 13:38

0

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 :)

answered Nov 18 '16 at 13:38

coderanger

52,400
4
52
75

Knife zero existing node discovery

2 Answers2