|
Post by jautor on Jan 30, 2024 15:29:01 GMT
Given the semantics of the PATCH operation on this property, you'd have to activate the power limit behind the scenes. Keep in mind, Redfish and IPMI aren't necessarily one-for-one; if you need to support both protocols, there will be cases where some operations in Redfish will cause multiple things to happen in IPMI, and vice versa. Thanks,for your quick response, now we need to support this feature from redfish side right? Given the direction of customer requirements for the power limit functionality, and the Redfish support expectations from OCP and other groups, that would be my recommendation... Relying on any IPMI-over-LAN functionality as a solution for the customer is not a good assumption at this point. Jeff
|
|
|
Post by jautor on Jan 10, 2024 1:50:42 GMT
See the relatively new (as of release 2023.2) `Decommission` Action defined in ComputerSystem v1.21 that is intended to cover this case. That action allows for portions of the system to be reset to factory defaults, or the entire unit (including user data).
Jeff
|
|
|
Post by jautor on Jan 8, 2024 20:49:45 GMT
This already seems to be a strech of the intended use of the Controls-Ressource. For my understanding it is meant for control loops such as PID-Controllers. In my usecase i want to switch digital outputs, which are "unconfigured" and not available in any functional view. Yes, it's a stretch... To expand more on my previous post, we felt a standard definition (schema/resource) for a "configurable analog/digital sensor input" wasn't worth pursuing. That opinion was based on the belief that such a definition would require a lot of very vendor-specific configuration options/items and that the only likely client software would be the product's own GUI. Now, if that opinion is incorrect - we'd certainly be willing to look at a proposal! At least for Sensor, it seems reasonable for that to just be added to the standard schema. Certainly not why I'd want anyone to create an OEM schema! Let me raise that with the group. For Control, see above, I think you're likely better off doing a full OEM schema for your "configurable input". You can disable OEM checks in the Validator's config options. Look at the mockup for "public-oem-example" mockup. Included in there is a "Contoso.com" folder that contains OEM schema extension examples. You don't. We avoid that if at all possible because it ruins the interoperability of the property... If you've got a ReadingType that we don't have in the list, please submit it as feedback and we'll see about adding it to the standard... And for the "OemDigital" - our expectation is that many of these analog/digital inputs, once configured, would just populate a single property or object in a resource, not necessarily expose themselves as a Sensor and/or Control instance. The example I can give now (since that schema has been published) is the relatively new "Doors" object in Chassis. If the user configured a couple of digital inputs to be "front door lock", "front door open/close sensor", etc. - you'd just populate the rack-level Chassis resource with: "Doors": { "Front": { "DoorState": "Closed", "Locked": false, "UserLabel": "Rack 42" } }
What is the output of that synthesized dewpoint sensor? Because we added a "DewPointCelsius" sensor excerpt to EnvironmentMetrics (with a ReadingType of temperature) - does that not cover it? If that value needs the sensor details - you can mark that Sensor "Implementation" as "Synthesized" to explain that. And remember that the Sensor excerpts don't *have* to have a full Sensor resource backing them if there's no user benefit. You could show the value in EnvironmentMetrics and omit the "DataSourceURI" property. Jeff
|
|
|
Post by jautor on Jan 8, 2024 4:48:44 GMT
Hi, I'm referring to Power.v1_7_1.json schema which defines the LimitInWatts property: "LimitInWatts": {
"description": "The power limit, in watts. If `null`, power capping is disabled.",
"longDescription": "This property shall represent the power capping limit, in watts, for the resource. If `null`, power capping shall be disabled.",
"minimum": 0,
"readonly": false,
"type": [
"number",
"null"
],
"units": "W"
}
My understanding: - If User PATCH LimitInWatts to a number value, this means the power limit setting is activated (like user uses ipmi dcmi activate command) - If User PATCH LimitInWatts to a null type, this means the power limit setting is de-activated (like user uses ipmi dcmi deactivate command) Please help to correct me. Thanks
That is correct. Note that in EnvironmentMetrics (the schema which replaced the deprecated Power schema), the PowerLimitWatts object has a ControlMode property that more explicitly shows the state of the power capping functionality.
Jeff
|
|
|
Post by jautor on Jan 7, 2024 20:31:44 GMT
Yes, any Redfish property defined as read-write in schema may be implemented as read-only.
|
|
|
Post by jautor on Dec 18, 2023 17:12:46 GMT
Awesome, thanks!
Jeff
|
|
|
Post by jautor on Dec 13, 2023 15:41:50 GMT
Hello, Recently I've started using an Interop-Validator. I'm going to recommend using of this tool inside my organization, but at this moment I see a kind of limitation(?), bug(?)... In test report I can see that unexisting resources/properties that are 'Recommended' or 'IfImplemented' have a status: PASS. It gives a false view on the status of service implementation. Also, it requires additional tester's work to ensure which results are 'true' PASS. From my perspective, if the object is not Mandatory and does not exist, then test should has a status: Not Applicable (NA). Good suggestion. So change that green "PASS" column to white (don't want to flag these as warnings/errors, obviously) with probably separate text for "not tested / not implemented" and "verify implementation" (for IF-Implemented cases where we can't tell if the property is required or not). Please open an issue on GitHub so that it can be tracked and assigned - and pull requests to make improvements like this are always welcome! That's another good suggestion - please open an issue for that, too! That second test line was probably added to call out the specific write requirement. But you're correct that it effectively gives the same information twice, and so it should collapse those into one line. There are relatively new payload annotations defined in Redfish for the service to indicate which properties it has implemented as Read/Write (@redfish.WriteableProperties) that will help the tool provide some more information about Read/Write properties in the future... Jeff
|
|
|
Post by jautor on Dec 12, 2023 19:20:31 GMT
There is no requirement to tie the `PowerState` to the `Status/State` property. But depending on your device, it certainly can make sense to change the `State` value to reflect the fact that it's powered off... If you do change the `State` value, I would suggest using the `StandbyOffine` value, assuming that the unit would become fully functional if someone pushes the power button.
Jeff
|
|
|
Post by jautor on Dec 8, 2023 18:26:27 GMT
1. When user provides different values for Host Name Part in FQDN attribute(for e.g. usersupport) and HostName attribute (adminsupport), we can throw 400 Bad Request stating both attributes need to be configurable without creating any conflicts. This is the simplest approach. Yes, if the PATCH request includes both properties, and they are in conflict with each other, 400 would be the appropriate response. And we have the Base message `PropertyValueConflict` to provide error details to the client. The issue we need to tackle (and are asking for feedback on the recommendation language) is what happens if the PATCH includes only one of those, and the value conflicts with the unchanged other property. My suggested text would recommend that a PATCH on FQDN that conflicts with the existing value of HostName could update the HostName value (as it's obvious?), assuming the client just didn't include it. But I would reject a change to HostName that conflicts with FQDN - because the service can't assume the correct value. The alternative (and perhaps the safer one) would be to recommend that both properties should be updated together... Jeff
|
|
|
Post by jautor on Nov 29, 2023 0:07:10 GMT
No, there is no requirement that an Action parameter have a corresponding property. One of the main purposes of "Actions" is to provide the means to perform tasks that do not fit into the RESTful model, and many of those require parameters to specify behavior. The most obvious example is `ResetType` in the commonly-defined "Reset" action.
Looking through the schema, there actually aren't very many cases where a parameter corresponds directly to a single property instance. In many cases that do, it's used as a selector for an array of objects in order to perform a non-RESTful operation.
Jeff
|
|
|
Post by jautor on Nov 28, 2023 23:43:15 GMT
We would certainly recommend that any and all firmware instances on the platform appear in the FirmwareInventory - as that is the purpose of that collection... Whether that firmware can be updated (via Redfish or some other mechanism) or not, being able to obtain the list of running firmware with version information, across vendor products, is a fundamental systems management task.
This is especially important for any firmware that can be updated via the Redfish service, as client tools that use the Redfish UpdateService will very likely use the contents of FirmwareInventory to determine what items can be updated.
Jeff
|
|
|
Post by jautor on Nov 27, 2023 19:16:23 GMT
I would absolutely recommend that you support both of these (when no parameters are required) without returning errors to the client. Allow either an empty JSON object or an empty request body. We have seen clients do both - and it has caused interoperability issues when the service rejects one method that another service allows (or requires!).
Jeff
|
|
|
Post by jautor on Nov 22, 2023 16:28:48 GMT
I could see us defining an another schema annotation for an "additional description" that could be combined with the `Description` text (merged, probably appended to the end of the description). That would allow an OEM to safely merge that text without replacing the "standard" description. We could add that merge to our doc-generator tool as well (it already has the capability to take replacement or additional property-specific text from a file separate from the schemas). And it would be straightforward to do the same for inserting that into the YAML.
The additional column (map to GUI or SNMP values, etc.) could be accomplished in the same manner - I suppose it could be something added only to those tables/schemas where that additional data is found... That one I need to think about more - but again, I see the usefulness of it for documentation.
But overall, your thoughts mirror mine and what we've done in our doc-generator tool - allow the addition of supplemental text stored separately from schema files - so that additional text can be maintained without touching the schema files. And new documentation can be generated from the latest schema without requiring updates...
Jeff
|
|
|
Post by jautor on Nov 22, 2023 16:16:23 GMT
I see. Thanks for reply. One more question, do you know how to get "SlotType" in general? I checked the PCI configuration space (https://en.wikipedia.org/wiki/PCI_configuration_space) but I didn't see a place to store this information. Michael
It won't be in PCI configuration space, because it's not a feature of the PCI device/chipset. You'll likely have to obtain that by a platform-specific lookup table - which is what SMBIOS is supposed to be.
|
|
|
Post by jautor on Nov 21, 2023 16:46:42 GMT
The PCIeSlots resource was deprecated in favor of the "Slot" object in PCIeDevice. Since a PCIeDevice resource collection was added quite a while ago to Chassis, having a separate, mostly static resource just to describe the slots became duplicative. So you populate the "Slot" object within a PCIeDevice resource for each slot. If the slot is empty, you populate it with an "Absent" State to allow discovery of that capability.
Redfish didn't carry forward the 20 years of obsolete values that can be represented in those SMBIOS tables, so yes, the values will be different - and the properties within "Slot" are more PCIe specific. But the end result should be much easier for the consumers of the data to comprehend.
Jeff
|
|