[CHEF-4732] ability to run ohai and save the collected info back to the server #1114

wants to merge 1 commit into


None yet

4 participants

jgoulah commented Nov 6, 2013

using this at etsy to save ohai info outside of a chef run


This is problematic in a couple of ways, but here you are wiping out all the attrs computed on the chef client run. That means you'll get different search results based on if you are searching right after a CCR or after this has run. Do a chef-client run and a 'knife node show > /tmp/node1' and then trigger a rehai and 'knife node show > /tmp/node2' and do a diff of the result. all your chef-client computed variables during the run will be different.

I think that if you just drop this line then you'll preserve default+override+normal and only update automatic which is probably more what you want to do.


So, overall I'm skeptical of this approach without knowing what your use case is in more detail.

One problem here is that there's no locking around node objects and chef already does a read-modify-save and races with anyone editing the run_list via knife at the same time. This will introduce more races. If you run it really aggressively then knife node run_list commands will get terribly unreliable (try running chef-client with no splay and no sleep on a node and it becomes impossible to update your run_list via knife).

Also if you're trying to turn ohai into a monitoring system to see variables that change -- like memory statistics, etc then you really want to use graphite+gdash+sensu rather than increasing your node.save frequency to the chef database to try to get fresh data. You'll be hammering on the database and hammering on solr indexing with the increased frequency of node.saves. What is changing so often on the servers that your normal converge cycle isn't fast enough, and why doesn't that thing better belong in graphite/sensu?

It just feels like you're trying to turn ohai+chef into graphite and chef is a really, really shitty replacement for graphite, and we're unlikely to fix that anytime soon. I picture someone deploying this to run every minute on their servers and then cutting a huge amount of tickets due to all these architectural issues which we will have to close wontfix, because chef isn't really architected to solve that issue...

I might be missing something here, but you're gonna have to explain how this is useful in a bit more detail, because my mind just leaps to all the ways that this could be horribly misused and I don't see the feature...

@btm btm commented on the diff Nov 11, 2013
+ # Create a reference to the node
+ node_name = Chef::Config[:node_name] || ohai[:fqdn] || ohai[:hostname]
+ Chef::Config[:node_name] = node_name
+ node = Chef::Node.find_or_create(node_name)
+ # Clear out existing attributes, some of these may have been deleted
+ node.reset_defaults_and_overrides
+ # Set the new attributes, the second argument here is the list of user
+ # supplied attributes from the command line or possibly a config file
+ node.consume_external_attrs(ohai.data, {})
+ # Write back to the server
+ node.save
+ # puts Chef::JSONCompat.to_json(node)
btm Nov 11, 2013 Member

This line should be removed or turned into a debug message.

@sersut sersut added the Discussion label May 20, 2014
sersut commented May 20, 2014

Thanks for taking a stab at this @jgoulah. This is a pretty cool tool. I'd recommend making a gem with this and the users who need this can get it into their Chef infrastructure.

I think this might be a great tool for monitoring scenarios. Especially when this is implemented in Chef. Before than this would conflict this the node saves that are already in operation. As @lamont-granquist described above this is currently not fitting into our roadmap.

Let me know if you still want to pursue this and we can reopen and discuss further.

@sersut sersut closed this May 20, 2014
jgoulah commented Jul 6, 2014

@sersut no problem, I can make a gem, in CHEF-4732 they had said there were good current and future use cases and this does solve a real issue for us. the attribute consistency proposal looks interesting to me..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment