- From: Bryan McLellan <
- Subject: [chef-dev] Reporting use cases
- Date: Sat, 1 Oct 2011 09:35:28 -0400
We're developing the requirements for reporting and we'd like to know
what use cases would be required or desired. We'll talk about the
architecture design at a later date.
1. Chef-client run success/failure 
* State of the client on run
* Log of run
* Expanded run list?
* How was the run initiated?
* User name
* Integrate with node status page
* Tracking run length (time)
2. Auditing access control
* Client creation / deletion
* Privileges (Admin on Open Source / ACLs on Hosted Chef)
* Ability to label run logging events or hook into reporting
* User cookbook
* Sudoers cookbook
3. Auditing object/resource changes
* Changes (creation/deletion/modification) to cookbooks, roles, nodes, etc.
* API Hooks for notification (HipChat, IRC Bot, Email)
* Full diffs of changes?
* Metrics regarding resource change
* Top 10 changing resources
* API endpoint for applications like munin, graphite, ganglia
* Number of nodes, runs, clients, etc.
* API endpoint calls, e.g. /cookbook/
* Length of endpoint calls, e.g. /search/
How long would you want or need access to this data? Why?
How much data would you need, e.g. a cookbook changed or a diff of
what changed in the cookbook? Why?
I'd appreciate any use case suggestions to be fairly descriptive and
include what needs to be logged, who wants it, and why they need it.
For instance "as the SOX compliance officer, I need to know that Chef
is configured to manage user accounts on all systems and be able to
confirm that it is actively doing so."
Bryan McLellan | opscode | senior systems administrator
(c) 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org
- [chef-dev] Reporting use cases, Bryan McLellan, 10/01/2011
Archive powered by MHonArc 2.6.16.