|
Post by mraineri on Feb 26, 2024 12:16:59 GMT
Yes, 200 OK is definitely preferred since it allows a service to show what devices were updated as a result of the firmware update operation. 204 No Content is allowed though; it just doesn't give the user any information as to what was updated. The Redfish Firmware Update White Paper (https://www.dmtf.org/sites/default/files/standards/documents/DSP2062_1.0.1.pdf) has examples of this along with recommendations for the standard messages to use. One thing I noticed is your example uses "UpdateService.1.0.FirmwareUpdateCompleted", which is not part of a standard registry. If this is an OEM message, the "OEM registries" clause of the Redfish Specification has rules for how companies can craft their own message registries to avoid potential conflict with standard registries in the future. With words on Spec. What do you mean by this? The headers and response body of the initial operation, as if it had completed synchronously. Your meaning is the response of synchronous operation preferred 200 OK with the payload like ginugeorge posted? Specifically for firmware updates, yes. There are a lot of details that a user may be expecting to be sent by the service as a result of a firmware update. Clients need to know what devices were updated as a result. In many cases, the image sent is a package, and the client doesn't necessarily know specific version or component information in them. For many other actions, 204 No Context works well. For example, if a client invokes a Reset action, there's really no additional information to convey.
|
|
|
Post by mraineri on Feb 23, 2024 20:50:28 GMT
Yes, 200 OK is definitely preferred since it allows a service to show what devices were updated as a result of the firmware update operation. 204 No Content is allowed though; it just doesn't give the user any information as to what was updated. The Redfish Firmware Update White Paper (https://www.dmtf.org/sites/default/files/standards/documents/DSP2062_1.0.1.pdf) has examples of this along with recommendations for the standard messages to use.
One thing I noticed is your example uses "UpdateService.1.0.FirmwareUpdateCompleted", which is not part of a standard registry. If this is an OEM message, the "OEM registries" clause of the Redfish Specification has rules for how companies can craft their own message registries to avoid potential conflict with standard registries in the future.
|
|
|
Post by mraineri on Feb 23, 2024 15:44:26 GMT
There's no requirement to have local copies of schemas.
However, if you do want to host local copies, we have this URI pattern specified in the "Redfish-defined URIs and relative reference rules" clause of the Redfish Specification for local schema files:
> /redfish/v1/Schemas/<SchemaFile>
|
|
|
Post by mraineri on Feb 22, 2024 15:56:42 GMT
That's entirely up to you and how you need to meet your product's requirements. DMTF does not define an "audit log"; we only go so far as to define the generic log mechanism itself. We also do not have standard events that map to what you're describing; the closest we have at this time is the "ResourceChanged" message in the Resource Event Message Registry.
However, I would certainly advise against doing any JSON dumps in the message itself. The Message string is meant to be human readable, so when you're crafting messages for your product, it would be good to keep that in mind.
|
|
|
Post by mraineri on Feb 22, 2024 13:44:11 GMT
That all still sounds like debug data in the scope of Redfish. Internal files like that on a BMC are not standardized as to their contents or structures. I would still recommend looking at the CollectDiagnosticData action (but in that specific usage you can use the parameter "Manager" as the data type).
However, if the data is consumable by Redfish clients, I would expect the data to be mapped accordingly to a hardened resource and not left as an opaque file.
|
|
|
Post by mraineri on Feb 21, 2024 13:38:19 GMT
If you're looking to get "critical data" off a system when SSH or other methods are not available, the existing CollectDiagnosticData action should let you do this in a fairly arbitrary manner. One of the options is to specify the type of data to collect, and "OS" is already one of the options. The result of the action will produce an opaque package that a user can download from the BMC.
Beyond this, doing proper file management on a system is out of scope for Redfish at this time.
|
|
|
Post by mraineri on Feb 19, 2024 20:35:39 GMT
Yes, you'd return 401 since the credentials are not valid over that interface. 401 is used to tell the client they need to specify different credentials to gain access. The IPMI bootstrap credentials are only allowed on the interface designated as the "host interface", which is typically a point-to-point network connection between the CPU complex and the BMC.
|
|
|
Post by mraineri on Feb 15, 2024 17:50:14 GMT
This can be covered by the existing "partial success of a PATCH operation" statements in the "PATCH (update)" clause. Your service successfully applied the first array index in the request, thus returning 200 OK is correct. However, you do need to include a message in the response indicating what was ignored/dropped. The "ArraySizeTooLong" message should work for this case to show the client that the remaining elements were dropped.
|
|
|
Post by mraineri on Feb 15, 2024 17:41:55 GMT
Because the settings resource definition inherit from the resource in question. So, if ComputerSystem did not contain read-write for the property, then a client would not be able to modify the property in the respective settings resource. Keep in mind the settings resource construct is generic in nature and this applies to every other usage of it. It can get even more complicated where you do have a mix of capabilities in these properties where it's possible to PATCH the same property in both the active resource and the settings resource. We have a lot of these behaviors described in the "Settings resource" clause of the Redfish Specification.
However, specific to the BootOrder property, the reason there's guidance to use a settings resource in this case is because on the vast majority of system architectures that exist today, it's simply not possible to change the boot order on the fly. UEFI needs to come back up, see the settings request, process it, and either apply it or reject it. In theory there could be some behind the scenes magic to modify UEFI's persistent storage to directly apply the new boot order without the need for UEFI to come back up and process the request; however I have never seen this capability in practice.
|
|
|
Post by mraineri on Feb 14, 2024 18:49:12 GMT
That's entirely outside the scope of Redfish since an end user has no control over that, nor do they realistically care about how you manage your BMC's internal storage. You can certainly do that, but that's all within your control to dictate how to push it to a remote server. But I think that sort of behavior is atypical, and I don't have much guidance on that.
|
|
|
Post by mraineri on Feb 12, 2024 13:40:28 GMT
In that case, yes; if all 10 supplied URIs in @odata.id are invalid, then showing 10 messages would be accurate. While it might seem extraneous, consider this: what if 5 were correct and 5 were invalid? You would have 5 specific messages with 5 related properties pointing to the exact ones that are wrong, thus the client knows the other ones in the request are okay.
However, you also need to consider other types of client request issues. For example, if the client provided a JSON object for "MetricReportDefinitions" instead of an array, then you'd only use "/MetricReportDefinitions" as the related property.
|
|
|
Post by mraineri on Feb 9, 2024 20:29:46 GMT
Response 2 would be correct.
RFC6901 specifies 0-based indexing of arrays when making a JSON path. In addition, while @odata.id is a special property, it's still the property that is in question with regards to what is wrong with the client request.
|
|
|
Post by mraineri on Feb 7, 2024 21:30:56 GMT
/redfish/v1/Chassis/{ChassisId}/NetworkAdapters/{NetworkAdapterId}/NetworkDeviceFunctions/{NetworkDeviceFunctionId}/EthernetInterfaces/{EthernetInterfaceId} is specifically for non-system types of interfaces. One example is an EBOF where there are network controllers embedded in an enclosure that serve as an NVMe-oF to PCIe bridge; there's no ComputerSystem here since it's a box of network-connected drives, but a user needs to be able to configure the IP address of those controllers. We have this in the long description for EthernetInterfaces in NetworkDeviceFunctions:
> This property shall not be present if this network device function is not referenced by a NetworkInterface resource.
For the case you're describing, you'd need to add EthernetInterface resources subordinate to the appropriate ComputerSystem resource to go alongside the NetworkInterface resources.
I'll admit this is not the most intuitive approach. We expected NetworkInterface, NetworkDeviceFunction, and other advanced communication device resources to replace EthernetInterface in the same manner Storage can fully replace SimpleStorage. Unfortunately as new use cases came up (virtual NICs, bonding, virtual machines, etc), we realized that EthernetInterface is still needed, and we likely would have taken a different modeling approach had this been apparent to us.
|
|
|
Post by mraineri on Feb 7, 2024 14:05:20 GMT
Yes, you can still use that action to change the password even if RequireChangePasswordAction is false. "RequireChangePasswordAction" only affects the ability to PATCH the Password property directly.
|
|
|
Post by mraineri on Feb 6, 2024 22:07:07 GMT
What exactly is your use case for allowing a user to add/delete/edit files on a system? SNIA does touch on some of these concepts with their file system modeling, but it doesn't go down to the level you're thinking of.
I have concerns with this sort of functionality since it's duplicative of other tools used to log into a system and edit files, like using SSH to the host and editing files over that interface. The OS already carries around permissions for who can access each of the files, and allowing Redfish to bypass the OS/recreate access rights for system files might be very problematic.
|
|