* Adding a resolved timestamp to phosphor-logging's event logs
@ 2020-02-25 18:58 Matt Spinler
2020-02-25 22:03 ` Gunnar Mills
0 siblings, 1 reply; 3+ messages in thread
From: Matt Spinler @ 2020-02-25 18:58 UTC (permalink / raw)
To: OpenBMC Maillist
To those that use phosphor-logging's openbmc event logs:
I just put up a phosphor-dbus-interfaces change
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/29734
to add a new ResolvedTimestamp property to the OpenBMC event log entry.
Next I'll update phosphor-logging to set that timestamp when the Resolved
property changes, so that users can know when an error was resolved.
Review if interested.
Thanks
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Adding a resolved timestamp to phosphor-logging's event logs
2020-02-25 18:58 Adding a resolved timestamp to phosphor-logging's event logs Matt Spinler
@ 2020-02-25 22:03 ` Gunnar Mills
2020-02-27 14:44 ` Matt Spinler
0 siblings, 1 reply; 3+ messages in thread
From: Gunnar Mills @ 2020-02-25 22:03 UTC (permalink / raw)
To: Matt Spinler, OpenBMC Maillist
On 2/25/2020 12:58 PM, Matt Spinler wrote:
> To those that use phosphor-logging's openbmc event logs:
>
> I just put up a phosphor-dbus-interfaces change
> https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/29734
> to add a new ResolvedTimestamp property to the OpenBMC event log entry.
>
> Next I'll update phosphor-logging to set that timestamp when the Resolved
> property changes, so that users can know when an error was resolved.
>
Redfish is adding a "modified" property to the LogEntry Schema.
https://redfish.dmtf.org/schemas/v1/LogEntry.v1_5_1.json
(Redfish issue 3854 for those that have access to the repo.)
Does it make more sense to have a Last Updated Time property on the
event log entry in D-Bus? Then this could map to the Redfish "modified"
property easier. This property would get updated when the event log was
resolved, unresolved, or any other action.
Thanks,
Gunnar
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Adding a resolved timestamp to phosphor-logging's event logs
2020-02-25 22:03 ` Gunnar Mills
@ 2020-02-27 14:44 ` Matt Spinler
0 siblings, 0 replies; 3+ messages in thread
From: Matt Spinler @ 2020-02-27 14:44 UTC (permalink / raw)
To: Gunnar Mills, OpenBMC Maillist
On 2/25/2020 4:03 PM, Gunnar Mills wrote:
>
> On 2/25/2020 12:58 PM, Matt Spinler wrote:
>> To those that use phosphor-logging's openbmc event logs:
>>
>> I just put up a phosphor-dbus-interfaces change
>> https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/29734
>> to add a new ResolvedTimestamp property to the OpenBMC event log entry.
>>
>> Next I'll update phosphor-logging to set that timestamp when the
>> Resolved
>> property changes, so that users can know when an error was resolved.
>>
>
> Redfish is adding a "modified" property to the LogEntry Schema.
> https://redfish.dmtf.org/schemas/v1/LogEntry.v1_5_1.json
>
> (Redfish issue 3854 for those that have access to the repo.)
>
> Does it make more sense to have a Last Updated Time property on the
> event log entry in D-Bus? Then this could map to the Redfish
> "modified" property easier. This property would get updated when the
> event log was resolved, unresolved, or any other action.
The thing about that Redfish property is that as soon as there is more
than one field that can be updated,
it becomes ambiguous as people wouldn't know what actually changed, and
so I haven't convinced myself
yet that is the right thing to do in phosphor-logging. I'll mull on it
some more, and I still welcome thoughts
on this from others.
>
> Thanks,
> Gunnar
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-02-27 14:44 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-25 18:58 Adding a resolved timestamp to phosphor-logging's event logs Matt Spinler
2020-02-25 22:03 ` Gunnar Mills
2020-02-27 14:44 ` Matt Spinler
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.