Design event logging mechanism

[dkodihal]

There is a need to log system events (for example DCMI requires them), such as system boot events, temperature/thermal events etc. This story is to investigate how the existing logging mechanism can be leveraged to do this, and to come up with new interface(s) is required.

[dkodihal]

Status

13 July : No progress. Working on PNOR bringup with new mboxd code. Delivery of that needs to happen in the next few days. Being a bringup activity, there's no story for this. Also spent a good amount of time reviewing code from almost everyone in the squad, and helped squad members with direction for the new sprint's stories and task breakdown.

14 July : No progress. Working on PNOR bringup with new mboxd code - addressing code review comments. Delivery of that needs to happen in the next few days. Also did code reviews.

17 July : No progress. Working on PNOR bringup with new mboxd code - addressing code review comments. Did code reviews.

18 July : Will start post #1489. Reviewed a lot of code from the squad.

24 July : Won't be able to complete this in the current sprint, moved it to the next.

• 08/18 : On hold because I'm working in Interface and implementation of the boot policy setting #2008.

[dkodihal]

STATUS

08/16 - Will start after completing 2102.
09/05 - Design proposals sent to the community.
09/07 - Haven't heard feedback from the team. Need to discuss this in a design meet asap.

[geissonator]

Team discussion today

• How much data we talking about here? Initially we're trying to tackle specific events like boot progress, over temperatures events.
  • Not super detailed things like a temperature sensor every 100ms
• Will we persist this? Yes, these will be persisted. Telemetry data will not be
• External client can subscribe to error logs, telemetry data, not error logs
• Say there's an overtemp, if we use error logging, no new dbus for this, but with option 2, we now need to do create this new interface
• Does this tie into IPMI? IPMI could be enhanced to look at these events to create errors
• yaml input to server side event? That way all apps can call notify, then system policy defined in yaml into server side so it'll just ignore whatever is not wanted for system
• phosphor-dbus-monitor already looks for events, and takes actions - can we have it create event objects based on signals
  • Majority of things we want events for already have signals, so dbus-monitor can just watch for them
  • Seems viable going this way, but could be complex as features build
  • Maybe create new app in current repo, they can share code but we have 2 apps
  • This app doesn't handle persistency, new app will need to handle it

[dkodihal]

Closing this because design has been discussed and tasks added to #2254.