[chef] Re: Re: Chef in "Pure Infrastructure-As-Code" Mode?

[Dan Adams < >]

On 24.06.2012 14:48, Dylan Northrup wrote:
> I like the 'infrastructure-as-code' idea, but for tracing changes 
> made
> by chef on a node I would prefer a way to log changes made to the 
> CMDB
> and by whom.  Without the automated procedures detailed later in this
> thread, there can be a disconnect between what's in git and what's in
> chef.  Being able to view logs of cookbook uploads, role changes,
> knife ssh runs would be tremendous from an operational perspective in
> tracking down what's changed recently (to which the answer is always
> "Nothing changed, honest. It just stopped working." ;-)
>
> I want to say I remember mention of increased logging at one of the
> ChefConf talks I viewed, but cannot be sure.  If this was available,
> it would be an invaluable operational tool.

Another approach to provide some of these abilities (in addition to or 
instead of some of the other measures mentioned) is to use a custom chef 
report handler, which is executed at the end of the chef-client run. 
Various handlers are available that will fire off a notification of what 
resources have changed on a node to eg graphite, nagios, a log, or 
wherever. Since chef is idempotent, in theory most chef-client runs will 
be no-ops and so changed resources will be rare and due to manual 
changes somewhere in your infrastructure. However, whilst this is true 
of simple recipes, it is not necessarily true of more complicated ones 
that use search and conditionals etc.

We are using a simple custom report handler to output to the console a 
list of resources that have changed on a run. However, we have 
additional requirements coming down the pipeline within the organisation 
to process this information in a more sophisticated manner, and more 
specifically to log it centrally somewhere and tie it to authorised git 
commits, in turn tying these to authorised change requests. The wider 
Chef is used within enterprises, the more common this kind of 
requirement will become I suppose.

Cheers

Dan