UpdateService: How to send Option and Target with ImagePost?

paligill
Minnow

Posts: 4

UpdateService: How to send Option and Target with ImagePost? Mar 25, 2024 18:39:17 GMT

Quote

Post by paligill on Mar 25, 2024 18:39:17 GMT

Hi
I am trying to figure how how i can send the HttpPushUriOptions and HttpPushUriTargets alongwith ImagePost using Redfish UpdateService. For example, i tried as under and got a message that i can either send image or data.

> curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/octet-stream" -X POST -T test/image.tar.gz -d '{"HttpPushUriOptions":{"HttpPushUriApplyTime":{"ApplyTime":"OnReset"}}, "HttpPushUriTargets":["/redfish/v1/UpdateService/FirmwareInventory/16718d87"]}' https:{bmc}/redfish/v1/UpdateService/update
Warning: You can only select one HTTP request method! You asked for both PUT
Warning: (-T, --upload-file) and POST (-d, --data).

In this case, the UpdateService can handle a wide variety of update targets (for example BIOS, NIC, PSU etc) and hence each target -
1. Can have a different image format.
2. Can support different ApplyTime options, etc.

I am trying to see how i can Post this as one request to create context between image, options and target?

Thanks

mraineri
Administrator

Posts: 1,056

UpdateService: How to send Option and Target with ImagePost? Mar 25, 2024 20:47:17 GMT

Quote

Post by mraineri on Mar 25, 2024 20:47:17 GMT

It sounds like you're mixing the usage with a multipart HTTP push update and the vendor-specific HTTP push update.

If you're trying to push using the URI provided by the HttpPushUri property, it takes two steps:

1) Perform a PATCH to /redfish/v1/UpdateService with "HttpPushUriOptions" and other nested properties in the request body to set the parameters for the next update.
2) Perform a POST operation to the URI provided by "HttpPushUri" with the binary image.

I would recommend using multipart HTTP push update since that will send everything in one shot with the parameters in a JSON form and the binary itself in a separate octet-stream form. There's an example of this payload in the Redfish Firmware Update White Paper here: www.dmtf.org/sites/default/files/standards/documents/DSP2062_1.0.1.pdf (see "3.1.2 Multipart HTTP push update").

paligill
Minnow

Posts: 4

UpdateService: How to send Option and Target with ImagePost? Mar 27, 2024 18:12:25 GMT

Quote

Post by paligill on Mar 27, 2024 18:12:25 GMT

Mike, Thanks for the reply and sharing info.

After looking at the spec i got following questions -

1. According to Redfish White Paper - `The "Update parameters" form can contain the following properties`. My understanding is that this "Update parameters" refer to "UpdateParameters" in the UpdateService schema redfish.dmtf.org/schemas/v1/UpdateService.v1_13_0.json. Is that correct?
- If above is true, then i see some discrepancy between "Redfish Firmware Update White Paper" and JSON schema as white paper doesn't mention ForceUpdate property (as its there in Schema UpdateParameters) and schema doesn't mention about "UpdateFile" (as its there in White Paper). Please let me know if i am missing something here?

2. AllowedApplyTime property values can differ from one inventory item to another (for example, PSU v/s BMC v/s some other FW entity). How can this be represented with current Redfish schema as i see ["HttpPushUriOptions"]["HttpPushUriApplyTime"]["ApplyTime"] as a global property under update service.

mraineri
Administrator

Posts: 1,056

UpdateService: How to send Option and Target with ImagePost? Mar 27, 2024 19:01:11 GMT

Quote

Post by mraineri on Mar 27, 2024 19:01:11 GMT

1) Yes, that's correct. It looks like we added "ForceUpdate" as a parameter after the paper was first published, so we should update the paper to be in sync with the schema. Thanks for catching that. "UpdateFile" is specific to the HTTP header usage with the multipart forms and is not described in schema.

2) Currently there's not a way to convey device-specific supported apply times for updates. For the context of the UpdateService showing allowable operation apply time values, this is a "service-wide" allowable setting. I think you're the first one to raise this type of condition, and we'd have to discuss this further internally.