Track history on each client check in on each node on the status page.

http://lists.opscode.com/sympa/arc/chef/2010-01/msg00030.html

It would be a good start to notify the server that we've completed our run successfully or we have failed. Then display this in some manner on the status page, like coloring the last checkin green on pass or red on fail.

The example reported by btm is the right first step here - we should just be able to report the status of the last run. There is a larger reporting feature that needs to be designed, but simply saying whether the run succeeded or failed would be enough, and could be accomplished with a fairly simple setting within the node object itself, as we do save it at several points during the run.

I've implemented the (easier) subset of this issue as suggested by Bryan/Adam. Basically:

• I've added a report handler (result_to_server.rb) to return the result of the Chef run to the Chef server, via the REST API as a normal attribute.
• If the run fails, the node is highlighted in red, CI-server style.
• Hovering over the "Last Checkin" field gives details of the run (so shows the exception on fail, and details of the updates made to resources if passed).
• The run passes in the timings, and backtrace on fail, too, so the functionality can be extended if required.

To enable, add to /etc/chef/client.rb:

report_handlers << Chef::Handler::ResultToServer.new
exception_handlers << Chef::Handler::ResultToServer.new

If the handler isn't present on the client, the node line will behave as before.

Pull from git@github.com:ajmfulcher/chef.git branch CHEF-385

We're a little concerned about where we store the data.

On the first case, we should totally implement some indication of successful runs, but storing this data as an attribute triggers an additional node.save, which triggers indexing, and wouldn't scale wonderfully. We'd like to find a better solution.

As for storing the results of the run, we definitely need to find a better data store than the attributes, but we don't know what this is yet.

Discussion continues.

Reopening to pick up during triage.

The node data isn't appropriate to store run history and we don't want to store it as a single blob. While we get access to see a past run, very soon we would want to be able to correlate the data.

The the purposes of other types of history, like auditing when someone adds a new client, we need to scope this into a larger reporting framework.

We're working on the initial design at Opscode and open up the discussion soon.

https://github.com/opscode/chef/pull/28