Event Logger Data Interfaces: Difference between revisions
(Created page with "Category:WebHob Documenting the event logger data interfaces and action models. The EVT is the EVent Tra == EVT == Bitbake uses a push-event model where it sends pickled P...") |
No edit summary |
||
| Line 2: | Line 2: | ||
Documenting the event logger data interfaces and action models. | Documenting the event logger data interfaces and action models. | ||
The EVT is the | The EVT is the Event Translation Layer, which receive a set of events from a Bitbake build run, and builds a in-memory record set describing the build. | ||
The DSI is the Data Store Interface that will poll new records from each of the EVTs assigned to it, and write them in permanent record. | |||
== EVT == | == EVT == | ||
Bitbake uses a push-event model where it sends pickled Python objects over XMLRPC to an event sink. | Bitbake uses a push-event model where it sends pickled Python objects over XMLRPC to an event sink. EVT receives Python objects describing the progress of a build run, and updates its internal state to match the state of the Bitbake server. It will generate a set of records describing the statistics and results of the build run, e.g. task records for all the tasks that did run, build records for all targets, etc. | ||
=== interface with bitbake === | === interface with bitbake === | ||
| Line 14: | Line 15: | ||
EVT will run resident in memory, connecting to the bitbake server and accepting events. It will have an internal state that will follow the internal state of the bitbake server. This allows the EVT to infer information about the server state, and export this information to the DSI. | EVT will run resident in memory, connecting to the bitbake server and accepting events. It will have an internal state that will follow the internal state of the bitbake server. This allows the EVT to infer information about the server state, and export this information to the DSI. | ||
The event list that it receives from Bitbake is documented here | The event list that it receives from Bitbake is documented here, together with standard actions being taken in Knotty and what should happen in EVT. | ||
{| | {| | ||
| Line 90: | Line 91: | ||
=== interface with EVT === | === interface with EVT === | ||
=== interface with the Data Store system === | |||
The data interface is based on the Django ORM. | |||
A definition of [[Django models]] for build and task information is available. | |||
== Artifacts analysis module == | |||
Once a Bitbake build is completed, it's artifacts are available for usage, inspection and download. The artifacts analysis module (AAM) will be launched by EVT at the end of a build, parse the generated artifacts and insert relevant data into the DSI. | |||
Revision as of 14:24, 31 May 2013
Documenting the event logger data interfaces and action models.
The EVT is the Event Translation Layer, which receive a set of events from a Bitbake build run, and builds a in-memory record set describing the build.
The DSI is the Data Store Interface that will poll new records from each of the EVTs assigned to it, and write them in permanent record.
EVT
Bitbake uses a push-event model where it sends pickled Python objects over XMLRPC to an event sink. EVT receives Python objects describing the progress of a build run, and updates its internal state to match the state of the Bitbake server. It will generate a set of records describing the statistics and results of the build run, e.g. task records for all the tasks that did run, build records for all targets, etc.
interface with bitbake
The bitbake server runs at IP:PORT location. A event server controller lives at IP:(PORT+2) accepting a XMLRPC interface with two commands: registerEventHandler and unregisterEventHandler.
EVT will run resident in memory, connecting to the bitbake server and accepting events. It will have an internal state that will follow the internal state of the bitbake server. This allows the EVT to infer information about the server state, and export this information to the DSI.
The event list that it receives from Bitbake is documented here, together with standard actions being taken in Knotty and what should happen in EVT.
| Event object type | action taken in Knotty | action in EVT | |
|---|---|---|---|
| bb.runqueue.runQueueExitWait | |||
| bb.event.LogExecTTY | |||
| logging.LogRecord | |||
| bb.build.TaskFailed | |||
| bb.build.TaskBase | |||
| bb.event.ParseStarted | |||
| bb.event.ParseProgress | |||
| bb.event.ParseCompleted | |||
| bb.event.CacheLoadStarted | |||
| bb.event.CacheLoadProgress | |||
| bb.event.CacheLoadCompleted | |||
| bb.command.CommandFailed | |||
| bb.command.CommandExit | |||
| bb.command.CommandCompleted | |||
| bb.cooker.CookerExit | |||
| bb.event.MultipleProviders | |||
| bb.event.NoProvider | |||
| bb.runqueue.sceneQueueTaskStarted | |||
| bb.runqueue.runQueueTaskStarted | |||
| bb.runqueue.runQueueTaskFailed | |||
| bb.runqueue.sceneQueueTaskFailed | |||
| bb.event.BuildBase | ignored | ignored | |
| bb.event.StampUpdate | ignored | ignored | |
| bb.event.ConfigParsed | ignored | timestamp entry | |
| bb.event.RecipeParsed | ignored | timestamp entry | |
| bb.event.RecipePreFinalise | ignored | ignored | |
| bb.runqueue.runQueueEvent | ignored | ||
| bb.runqueue.runQueueExitWait | ignored | ||
| bb.event.OperationStarted | ignored | timestamp | |
| bb.event.OperationCompleted | ignored | timestamp, operation complete, timing | |
| bb.event.OperationProgress | ignored | ignored | |
| bb.event.DiskFull | ignored | error |
interface with DSI
DSI
interface with EVT
interface with the Data Store system
The data interface is based on the Django ORM. A definition of Django models for build and task information is available.
Artifacts analysis module
Once a Bitbake build is completed, it's artifacts are available for usage, inspection and download. The artifacts analysis module (AAM) will be launched by EVT at the end of a build, parse the generated artifacts and insert relevant data into the DSI.
