Inspecting version of environment that is attached to node



I’ve been recently puzzled on how to inspect / record what environment version was used to converge a specific node.

My use case - node foo is assigned to environment X, which defines common settings for cluster of nodes - for example, a DB connection string.

At some point of time DB connection string changed in environment file, but because chef no idea of versioning for environments, he won’t be able to trace that change and only source control can be used to know that environment was changed.

When that change happened, chef-client can be run on node foo to propagate DB connection settings to services, which sounds trivial to do if you run chef-client in daemon mode.
Let’s presume that convergence happens using chef-client in daemon mode, then how would I be able to trace propagation of specific environment across all nodes within specific cluster?

To me trace-ability of propagation is way to attach an information to node on successful chef-client run which will contain a version of environment (let’s say that is SHA256 of environment json file, or source control revision) which then becomes searchable from chef and auditable.

I wonder, if there is available solution to that ? Or there is some chef API that allows to pull current environment signature during chef-client run from chef server ?

With regards, Ignat Zapolsky


You can see it by watching the snapshot of node attributes saved back to the Chef Server after convergence succeeds. You can use a filtered search to get just that one new attribute for every node, and see which have succeeded with the new value so far.


Thanks, that is doable but cumbersome for situation when multiple changes are applied to environment file though.

After some deliberations we probably will implement scheme when we have a non-source-controlled cookbook that will have just 1 attribute with git revision number that will be taken from git.
That cookbook will have just one version, so whatever attribute value is resolved will be “current” git revision number.

Why “current” - I’ve looked into chef_client code and it seems that there can be race condition so that value does not necessarily represent actual git commit.

With regards, Ignat Zapolsky