action #49202
closed
Make audit events more accessible to testers
Added by livdywan about 5 years ago.
Updated over 3 years ago.
Category:
Feature requests
Description
The audit events which can be found on https://openqa.suse.de/admin/auditlog and https://openqa.opensuse.org/admin/auditlog respectively in production currently look like so
acarvajal job_restart { "id": "2539127", "result": { "2539127": 2540030, "2539128": 2540031, "2539129": 2540032, "2539130": 2540033 } }
coolo job_create { "id": 2540028 }
system command_enqueue { "command": "cancel", "workerid": 1061 }
cfconrad jobtemplate_delete { "id": "16093" }
cfconrad jobtemplate_create { "affected_rows": null }
With the PR fixing the value of affected_rows the last example might look like so
cfconrad jobtemplate_create { "affected_rows": 2 }
Two kinds of problems are common to all of these events:
- the IDs require knowledge of the code to construct a URL or SQL query
- some values on their own are not sufficient to make use of, such as the number of rows affected
To fix this I'm proposing:
- Events carry the minimum info needed to lookup the real data ie. iso_create only needs to contain the product id
- The audit log UI should link to the relevant page, making it easy to check the details ie.
Job 1234 restarted would be a hyperlink displayed for events of type "job_restart"
human-readable names be used in the events which don't require knowledge of the codebase
Acceptance criteria¶
- AC1: All events have an id
- AC2: Events have a clickable link
I like the idea of better human readable logs.
- Subject changed from Add human-readable names to audit events to Make audit events more accessible to testers
- Description updated (diff)
- Category set to Feature requests
- Priority changed from Normal to Low
- Target version set to Ready
- Description updated (diff)
- Status changed from New to In Progress
- Assignee set to livdywan
- Description updated (diff)
A few points came up during an impromptu meeting:
- We can drop job settings from events, because they are part of the job, provided we have the id
- Posted isos end up in the product log, so we can link to that w/o storing data in the event
- The restart event could be made useful by adding (git) versions to it
- We should define the use cases for the audit log (events) and consider dropping events, or at least in the context of this ticket, focus on useful events
We all agreed to keep this focussed on the basics. There should be no big changes involved.
cdywan wrote:
- The restart event could be made useful by adding (git) versions to it
I filed #70906
- We should define the use cases for the audit log (events) and consider dropping events, or at least in the context of this ticket, focus on useful events
Í'm not sure where we would best document this. Might make sense to leave for another ticket to avoid dragging this out.
On that note I will consider this as done as per the criteria once the respective PRs are merged.
- Status changed from In Progress to Feedback
- Status changed from Feedback to Resolved
All rolled out on o3. I think it works nicely and I see the ACs fulfilled.
Also available in: Atom
PDF