|
|
Post by AMI_Mani on Sept 20, 2023 16:22:59 GMT
Hi, When I refered redfish.dmtf.org/schemas/v1/Sensor.v1_7_0.json, seems there is no option to map discrete sensor state under Status -> State attribute. State atribute is supporting below enums only State: { enum: [ "Enabled", "Disabled", "StandbyOffline", "StandbySpare", "InTest", "Starting", "Absent", "UnavailableOffline", "Deferring", "Quiesced", "Updating", "Qualified" ], In case of discrete sensors has states like below Physical Security (Chassis Intrusion)
General Chassis Intrusion Drive Bay intrusion I/O Card area intrusion Processor area intrusion Platform Security Violation Attempt
Secure Mode (Front Panel Lockout) Violation attempt Pre-boot Password Violation - user password Pre-boot Password Violation attempt - setup password Pre-boot Password Violation - network boot password Other pre-boot Password Violation Out-of-band Access Password Violation How we can represent above states in Sensor schema? Is it possible to add SensorState attribute in sensor schema or needs to use OEM under Status like below "Status": { "Health": null, "HealthRollup": null, "State": "Enabled", oem { "SensorState":"Secure Mode (Front Panel Lockout) Violation attempt" } }, If any other attribute available to represent sensor state already, please point to that in Sensor schema Thanks, Mani |
|
|
|
Post by mraineri on Sept 20, 2023 17:05:10 GMT
You wouldn't map things like that. Sensors in Redfish are analog readings from a particular measurement point, such as a voltage monitor. The IPMI concept of "discrete sensor" does not map to Redfish as a generic "Sensor", and for the sake of interoperability, are intended to be mapped to explicit properties in the model.
|
|
|
|
Post by AMI_Mani on Sept 20, 2023 17:27:34 GMT
Hi,
Thanks for reply. What is the way to expose sensors like Chassis Intrusion in Redfish. My understanding is sensor schema needs to incorporate all type of sensors. End user expects all Sensors from IPMI needs to expose in Redfish.
Do we have any plan in future to represent "discrete sensor" in redfish? If there is limitation or any reason for not mapping "discrete sensor" from redfish point of view, please explain. Most of user switching to redfish from IPMI expecting way to expose "discrete sensor" in Redfish. If there is difference resource available to map "discrete sensor", please let me know
Thanks,
Mani
|
|
|
|
Post by mraineri on Sept 20, 2023 18:16:21 GMT
Specifically for "Chassis Intrusion", there's a "PhysicalSecurity" object in the Chassis resource that contains this info.
We intentionally do not map "IPMI Discrete Sensors" in the manner you're speaking since we have an entire object model to encode the information in an interoperable manner. There's no limitation in Redfish, but rather choose this path as a design choice since showing a generic "discrete sensor" provides less of a concrete definition to a user than a purpose-built property with hardened language about its behavior in the model. For example, if we introduce a "DiscreteSensor" resource, and implementations start encoding "Presence" and "Health" into it, a client loses a significant amount of context going through that generic collection and needs to perform additional work to map these readings to hardware components. The states are also a never-ending list; when confining the definition to a single hardened property, you can control the exact values that can be applied to the property, but we lose this with a generic "discrete sensor".
|
|
|
|
Post by AMI_Mani on Sept 20, 2023 19:23:52 GMT
Hi,
I understand about the possibility of mapping "Chassis Intrusion" with "PhysicalSecurity" in Chassis resource, but we can't map Platform Security Violation Attempt which may be need by user, simlarly we have many sensors like processor, memory, system firmware progress not possible to map. I understand the problem of state never ending list(many enums), but we can provide as string which can help user to view discrete sensors
Thanks,
Mani
|
|
|
|
Post by jautor on Sept 20, 2023 19:31:24 GMT
Hi, I understand about the possibility of mapping "Chassis Intrusion" with "PhysicalSecurity" in Chassis resource, but we can't map Platform Security Violation Attempt which may be need by user, simlarly we have many sensors like processor, memory, system firmware progress not possible to map. I understand the problem of state never ending list(many enums), but we can provide as string which can help user to view discrete sensors Thanks, Mani
A "Platform Security Violation Attempt" would just become a property in the Redfish model, either as a simple boolean if the states can be expressed as true/false, or as a enumeration if there are more than two states (or they can't be easily mapped to true/false).
The result looks like what you had suggested anyway:
{ "PlatformSecurityViolation": "FrontPanelLockoutAttempt" }
Where you'd have an enumeration of "None" to indicate there was no problem...
But this seems like something that should be reported as a message (and a LogEntry), so that it can appear as an active "Condition" in the "Status" object for the Systems/Chassis. Especially since you could appear to have multiple values at the same time?
Jeff
|
|
|
|
Post by AMI_Mani on Oct 25, 2023 17:56:31 GMT
Thanks for the reply. Since many of users wants to see all sensors from redfish(similar to IPMI), how it can be achieved from redfish. There is less chance for multiple values, so how we can represent discrete sensor in generic approach
Mani
|
|
|
|
Post by mraineri on Oct 25, 2023 18:45:36 GMT
You need to perform your discrete state mapping to the equivalent in the Redfish model. Having a generic "discrete sensor" model breaks interoperability and hardening of the data model, and is not something I think is worth pursuing.
For example, if you want to reflect information from the IPMI "Power Supply" sensor type (0x08), you could map bit 0 into the Status/State property for a PowerSupply resource. The remaining bits would also need to be mapped accordingly to the data model (such as factoring into the Health of the PowerSupply resource, the Conditions array property to show messages about the power supply, the LineInputStatus property, etc).
|
|
|
|
Post by AMI_Mani on Oct 26, 2023 14:08:59 GMT
I understand your point about generic "discrete sensor" model breaks interoperability and hardening of the data model. What is the generic way to represent these logical devices instead of using sensor? Since user needs to know about this entities, Do we have any way to achieve using standard schema(like task monitor has no schema and using for tasks)?
Thanks,
Mani
|
|
|
|
Post by mraineri on Oct 26, 2023 14:52:39 GMT
No, there's no generic way. You need to perform the mapping of discrete sensor states to properties in the model. In some cases there's an enumeration property that conveys several states for one thingy (like the DoorState property in the Chassis resource), or perhaps a simple boolean for a simple true/false state (like the HotPluggable property in the PowerSupply resource). I'm not also following your usage of task monitor as an equivalent; task monitor responses are either:
- Empty (no response body, but the task is still in progress)
- Follow the Task schema (if the task is still in progress and the service wants to convey task information)
- Follow the schema definition for the response of the original operation (if the task is complete); this will vary depending on the original request
All of the above are hardened in the spec and schema. |
|
|
|
Post by AMI_Mani on Oct 26, 2023 17:43:26 GMT
Thanks for reply. Task monitor doesn't have defined schema which will change according to task state. I'm asking any possibility of adding like that for discrete sensor, if we have some generic way to define entities according to server, it will be helpful, otherwise we have to define OEM attribute/OEM schema for this. Also there is very less chance for IPMI specification to change and whatever discrete sensor state available in IPMI can be mapped with enumerations which will not change most of the times
Thanks,
|
|
|
|
Post by mraineri on Oct 26, 2023 19:10:30 GMT
The task monitor response is certainly schema-backed; it's just not as crisp as other resources where you can state that all GET responses map to a single schema file. The schema definition is contextual based on the state of the task and the original operation request.
There is no desire to create a generic discrete sensor model due to interop concerns that would introduce. The design pattern in Redfish is to have hardened models to represent pieces of information in an interoperable manner. When you have a generic bucket of discrete sensors, you now put a burden on the client to translate each discrete sensor to something physical in their environment, which defeats the purpose of having a data model.
|
|
