Why server node information is different from node itself?


#1

Hello,

I specified override attribute value for environment to have [chef_client][config][interval] = 180. It showing as such on Chef server under “Attributes” for the node

While on the node itself client runs still using default 1800 run intervals per log file and client.rb

[2016-05-17T16:51:26-07:00] INFO: Child process exited (pid: 3012)
[2016-05-17T16:51:26-07:00] INFO: Next chef-client run will happen in 1800.4432039080762 seconds


#2

What platform/os are you running the client on? Has the chef-client service been restarted since the last client run?


#3

It’s running on Windows and service has been restarted several times with no effect.


#4

Is chef_client::config in the run list ? (Sorry, I have to ask to be sure :p)


#5

No I don’t have it. Am I supposed to have it to enable attributes override? My node is part of “production” environment which has default and override attributes set. Am I supposed to manually call chef_client::config in addition to that as well?


#6

As far as I remember yes, unless I did miss inclusion of the cookbook code in the client itself (which is possible) you need to use the chef-client cookbook here to tell it to use the chef_client attributes to configure the client.rb/daemon etc.


#7

I’m new to Chef as you can see so a little confused what steps I need to take. I modifed metadata.rb in my cookbook to have dependency on “chef-client”, I created a new recipe in cookbook called “servicesetup.rb” the only line in that recipe is 'chef_client::config’
I added this recipe to runlist for my node.


#8

If you’re new I recommend taking the tours at https://learn.chef.io, specially the one about managing a web app ( https://learn.chef.io/manage-a-web-app/windows/ ).

All in all, the line in your recipe should be include_recipe chef-client::config (what is before the :: should be the cookbook name)


#9

Thanks I already went through entire Windows training (that’s what got me to as far as I’m now).
The only question left is why configuration which is reflected on server for node is different from actual configuration on the node? (like it’s shown in original post)


#10

You can’t configure chef-client via the server (as this would be paradoxical, the client needs its config in place to know which server to talk to in the first place). You configure chef-client via /etc/chef/client.rb or a related config file. There is a recipe in the chef-client cookbook to write out a client.rb template based on node attributes, just like you can configure Apache or MySQL using Chef templates. There is no direct link between node attributes and Chef’s configuration.


#11

client.rb file is in fact modified by attribute overrides set on server on my node. When I added those values (for [config][interval]=180), those in fact were added to client.rb on node once chef-client pulled latest config.


#12

Then you are using that recipe or wrote your own similar recipe. Not sure what you are asking.


#13

​Yes, recipe had “chef-client::config” in it but attributes were pulled from server.
What I’m asking is why chef server had wrong information about the node. It said that chef-client on the node had interval set to 180 while in fact client was still at default of 1800.


#14

Both were right, chef-server had the node object from previous run where the attributes were set, but you didn’t have a recipe using this attribute at first.

Think of the node object on the chef server as the description of what you wish on the node (declarative model), not of the actual state of the node. (I’m omitting the automatic attributes from ohai there)

The important thing is that attributes alone does nothing. They are just information, if there’s no code (recipe) acting according to them, nothing happen :wink:

I hope this clear a little the original confusion.


#15

So attributes listed on Chef server for a node is not actually data coming from the node itself but rather how chef server calculated what settings supposed to be on a node based on existing runlist on server?


#16

There’s a bunch of possibilities to work on the node object, editing it, what the node saves back to the server after a successful run, etc.

Attributes can be gathered in two way, ohai to get them from system state (level of precedence automatic) and a merge from different level of precedence from environment, roles and cookbooks (attributes files are loaded first, then recipes are compiled and then resources from the compilation are converged), you can play at every level with attributes (WARNING it’s super easy to shoot yourself in the foot there).

The docs site has a long description about attributes and attributes precedence.

(and heading to bed, will give link tomorow if you don’t them yourself)


#17

I got it 100% working while using Chef Server default attribute values for my Role and having chef-client::config in my runlies. But I’d rather have this attribute to be setup as part of my cookbook though. Per my understanding and your explanation I can have following lines to my default.rb in “attributes” folder of my cookbook.

default['chef-client']['interval'] = 180
default['chef-client']['splay'] = 30

Output of chef-client contains line below which makes me suspicious that I missed something

  • ruby_block[reload_client_config] action nothing (skipped due to action :nothing)

#18

So node attributes are evaluated at compile time and if convergence succeeds, are saved back to the node on the Chef server. However, the presence of an attribute does not mean that it’s something that came from the node… you can define attributes like another poster said in multiple locations (environments, roles, nodes, etc) so what you see on the node is not necessarily what the node is configured with—it’s more a definition of how the node should be configured. And if you update these settings on a node, they don’t actually do anything until chef-client runs again on the node.

It’s helpful for troubleshooting but don’t consider it gospel unless you’re specifically looking at attributes that are coming from Ohai.

Nathan Clemons
DevOps Engineer
Moxie Cloud Services (MCS)

O +1.425.467.5075
M +1.360.861.6291
E nclemons@gomoxie.com
W www.gomoxie.comhttp://www.gomoxie.com/