Ideally you’d have your code in DVCS, cough git-repo(s) cough somewhere and you’d know what you’re configuring.
If you are coming into a new environment I’d ask where the code is stored and learn how it’s leveraged instead of going to a node to see what’s controlled by chef.
That being said, I don’t know of a knife command, it’s not really in scope, or a chef-client command.
Chef being a non-declarative system, has fewer static analysis options than Puppet (and Salt and Ansible). Tracking it during the run and then saving the list would be possible, but difficult to implement. Also would it include things like files from packages Chef has installed?
there are limitations. but for 80% cases you can do this by a handler that
taps into resource_completed event and checking if the resource is file or
template, if so add the path to a hash key
Chef.event_handler do
on :converge_start do
@accum = Hash.new(0)
end
on :resource_completed do |r|
if %i(file template cookbook_file).include? r.resource_name
@accum[r.path] +=1
end
end
on :converge_complete do
puts @accum.inspect
end
end
Thanks for the information on the chef.event_handler certainly test things out a little, but not 100% sure if that is the most logical choice.
Hi jjasghar
Not sure why it would be out of scope for chef-client or why one would always want to rely on filtering through code i.e. we have over 60+ cookbooks on some nodes and how some cookbooks have been managed is interesting i.e. version x of cookbook might change xyz file but a version six months later might not touch that file and implement things differently knowing that chef has changed files is surely very useful and doing it locally to the node is also highly useful.
yum.log is a great example as well as being able to run something like rpm verify.