mirror of
https://github.com/xcat2/confluent.git
synced 2026-09-05 20:47:57 +00:00
Markus Hilger
233fc9ec5a
The redfish event log was taken from every log service the manager advertises, whatever those turned out to be. On a bmc that keeps its systemd journal there, nodeeventlog answered with a thousand lines of kernel probe failures and daemon chatter, and the log the user asked for was never read at all, because this implementation keeps it under the system. Clearing was worse: of the services it did find, the ones with a clear action were the dumps, so a clear destroyed diagnostic data, left the event log untouched, and reported success. Judge a log service before reading it. A service whose id or name says journal, dump, post code, host logger or crash is not an event log, and both reading and clearing skip it, so a clear can no longer take out something that was never asked for. If that leaves the manager with no event log at all, look under the system, where such an implementation keeps it. Only then: a bmc that has one under the manager is served exactly as before, from the same requests, so this cannot change what an implementation that already worked reports. The list of services was also being extended in place, and it belongs to whatever the url cache is holding, so an extra log added by an oem handler accumulated on every call within the cache window.