Audrey Reporting

Audrey Reporting

High level summary of reporting goals

The goals of reporting in Audrey include:

• provide on-demand feedback of deployments
• provide capabilities for debugging deployment errors

The goals of reporting in Audrey exclude:

• the mechanism(s) for displaying the collected reporting data
  • it is assumed that an outside system (probably Conductor) will use an Audrey Reporting API to gather the collected Audrey reporting data
• the mechanism(s) for collating the collected reporting data
  • it is assumed that outside systems that display the Audrey reporting data will have their own preferences for organizing the data

Reporting Data Elements

Instance data

• registered: Conductor has posted the configs for the instance to the config server
• contacted: the instance has contacted the config server
• complete: all services on the instance are configured
• incomplete: the instance has stopped trying to configure and some of the services are not finished
• timestamp of last contact: the last time the instance contacted the config server

Service data

• complete: the service on an instance has finished configuration (show the configuration status)
• incomplete: the service on an instance is not yet configured
• timestamp of configuration start: the time that the configuration started for a service
• timestamp of configuration end: the time that the configuration ended for a service

Deployment data

• registered: conductor has posted configs for all instances in a deployment to the config server
• complete: all the services of all the instances in the deployment are configured
• incomplete: some of the services on the instances in the deployment are not yet configured
• unresolved dependencies: some of the instances have not provided all of the “return” values (or service execution output)

Config Server data

• running: the config server service is running

API

https://www.aeolusproject.org/redmine/projects/audrey/wiki/Audrey_Reporting_API

The initial implementation for the Config Server Reporting API will be an RPC/HTTP interface, staying in line with the other existing Config Server APIs.

Endpoints

• /reports/deployment/$UUID
  • This endpoint will provide access to data specific to the requested deployment UUID. The data will be returned in an XML format (tbd).
• /reports/instance/$UUID
  • This endpoint will provide access to data specific to the requested instance UUID. The data will be returned in an XML format (tbd).
  • Additionally, the XML returned from this call will also include data for all the instance’s services (see services endpoint).
• /reports/instance/$UUID/service/$NAME
  • This endpoint will provide access to data specific to the requested instance’s UUID and service. The data will be returned in an XML format (tbd).

Next steps

• work with Conductor team to understand what reporting framework conductor will use
  • last I heard this was not a current concern for that team (gdb – 13mar2012)
• decide how to gather the data that is not currently gathered in config server
  • timestamp of last contact by instance
  • timestamp of configuration start
  • timestamp of configuration end
• design API for accessing reporting data from config server
• decide if a config server web UI for accessing some reporting information is useful