|
|
Post by lucashorigan on Mar 22, 2024 21:44:28 GMT
Inside of document DSP0268, version 2023.1 on section 4.3 Condition here: www.dmtf.org/sites/default/files/standards/documents/DSP0268_2023.1.htmlThe common object Condition is given with a list of properties and not much else context. I have the understanding that Conditions are supposed to be used for system alerts for something such as a physical machine giving an alert for a temperature reaching too high of a point. This property never seems to be used in any of the published mockups here however: redfish.dmtf.org/redfish/mockups/v1Is there any example of how Conditions work and what the broader logic of them are? For instance inside of a Redfish template, are there two places for a condition to be placed? Such as the manager and a reference inside of a specific sensor endpoint? Any more context on this topic would be appreciated. |
|
|
|
Post by jautor on Mar 24, 2024 1:09:05 GMT
Yeah, that's a good point, we do need to add some realistic examples in the public mockups... But your understanding is correct. Conditions within the Status object is intended to report details about items that "require the attention of the operator", which may be due to something wrong shown in the resource itself, or may be a "health roll-up" item from a subordinate resource. Here's an example from the Redfish Release overview for 2020.4, when Conditions was added to the schema:
 In that example, a StorageController resource is reporting an issue with its cache module, and also an attached Drive has an issue (the OriginOfCondition points to that Drive resource to get the details on that issue...)
Furthermore, since then we also crated the ServiceConditions resource, off of the ServiceRoot, to allow the service to provide a one-stop place to get any condition, service-wide, that requires user attention. (those Release presentations are also bundled up as the Redfish Release History: redfish.dmtf.org/schemas/Redfish_Release_History.pdf ) Hope that helps, Jeff |
|
|
|
Post by lucashorigan on Mar 25, 2024 14:36:21 GMT
Yeah, that's a good point, we do need to add some realistic examples in the public mockups... But your understanding is correct. Conditions within the Status object is intended to report details about items that "require the attention of the operator", which may be due to something wrong shown in the resource itself, or may be a "health roll-up" item from a subordinate resource. Here's an example from the Redfish Release overview for 2020.4, when Conditions was added to the schema:
In that example, a StorageController resource is reporting an issue with its cache module, and also an attached Drive has an issue (the OriginOfCondition points to that Drive resource to get the details on that issue...)
Furthermore, since then we also crated the ServiceConditions resource, off of the ServiceRoot, to allow the service to provide a one-stop place to get any condition, service-wide, that requires user attention. (those Release presentations are also bundled up as the Redfish Release History: redfish.dmtf.org/schemas/Redfish_Release_History.pdf ) Hope that helps, Jeff Thanks for the information Jeff. That example helped. One small correction I noticed is that TimeStamp in CSDL is just Timestamp. I was able to implement that example now though. Thanks. |
|
|
|
Post by jautor on Mar 25, 2024 16:38:08 GMT
Oh- good catch! I'll update that presentation!
|
|
