|
|
Post by ratagupt on Sept 23, 2022 12:02:05 GMT
Hi Team,
SPDMGetSignedMeasurements in the component integrity schema seems synchronous API.
I was thinking that it should be asynchrounus one and it should be implemented with task based approach
In our use case this action is taking > 30 sec, if all the indexes is being requested in the action request, Hence we can not make it synchronus API.
Should we use the Task based approach here? If yes then how we should give the action response (SPDMGetSignedMeasurementsResponse) as part of task data.?
"SPDMGetSignedMeasurements": {
"actionResponse": {
"$ref": "#/definitions/SPDMGetSignedMeasurementsResponse"
Eg Action request:
curl -d '{"MeasurementIndices" : [1,3,5,7,11,15,21,25] }' -X POST http://<ip>/redfish/v1/ComponentIntegrity/<ID>/Actions/SPDMGetSignedMeasurements
{
"HashingAlgorithm": "TPM_ALG_SHA_384",
"SignedMeasurements": "EeAAARFgAAABCwAAAQEHAIMEAAAAAAEe6TasIa7Yqpy3SS7LUHSPahsgfjashfkjahfkSHDkjfhaskjfhAAAAAAAAAAAAAA",
"SigningAlgorithm": "TPM_ALG_ECDSA_ECC_NIST_P384",
"Version": "1.1.0"
}
curl -d '{"MeasurementIndices" : [1,3,5,7,11,15,21,25,30,41,51] }' -X POST http://<ip>/redfish/v1/ComponentIntegrity/<ID>/Actions/SPDMGetSignedMeasurements
{
"HashingAlgorithm": "TPM_ALG_SHA_384",
"SignedMeasurements": "EeAAARFgAAABCwAAAQEHAIMEAAAAAAECAAAAAAECAAAAAQECAAAAAgECAAAAZq3Q0VTpz9b+JrE6iC57aqeWFKE3fL07rHqIRhZ7wHoAAHtslS+eUu/T0GvkZmY6nv/sbKvN5oNw7AF04yxxP+/N2W1HqW41Qb6m7dqGIQzKATqHiT/18M52E/7/YgspNotDj+TylwWalVCatLyHeJl5ydTwXISqrDGXvpTsG+V9Lg==",
"SigningAlgorithm": "TPM_ALG_ECDSA_ECC_NIST_P384",
"Version": "1.1.0"
}
Ratan
|
|
|
|
Post by mraineri on Sept 23, 2022 13:27:31 GMT
The data model does not stipulate when something is asynchronous or not. In theory, every non-GET operation can result in a task. It's up to the designer of the implementation to determine when it's appropriate to spawn a task for a given operation. I can certainly see a task being needed for this type of action given how long the end-to-end operation can take.
In terms of the response payload, you do not include the action response in the task itself. When a client performs an operation that spawns a task, the client will get back a task monitor URI in the Location response header. The client polls this URI with GET operations until the task is complete. While the task is still being processed, the response from the GET on the task monitor URI will be the task resource. However, once the task is complete, the GET operation on the task monitor URI will respond with the result of the operation as if a task was never produced.
Keep in mind, there is a distinction between a "task resource" and a "task monitor". A task resource is the data model representation of a long running operation, and an administrator can discover these instances in the task collection. A task monitor is a special handle the client invoking the operation receives in order to get the final results of the operation.
|
|
|
|
Post by ratagupt on Sept 26, 2022 4:28:18 GMT
Yes got it, Let me confirm it with an example.
Step 1: Perform the POST action:
=====================
Request : curl -d '{"MeasurementIndices" : [1,3,5,7,11,15,21,25] }' -X POST http://<ip>/redfish/v1/ComponentIntegrity/<ID>/Actions/SPDMGetSignedMeasurements
Response: { "@odata.id": "/redfish/v1/TaskService/Tasks/0", "@odata.type": "#Task.v1_4_3.Task", "Id": "1", "TaskState": "Started", "TaskStatus": "OK" }
Step 2: Monitor the task:
===============
GET /redfish/v1/TaskService/Tasks/0
{
"@odata.id": "/redfish/v1/TaskService/Tasks/0",
"@odata.type": "#Task.v1_4_3.Task",
"Id": "0",
"Messages": [
{ "@odata.type": "#Message.v1_0_0.Message", "Message": "The task with id 0 has started.", "MessageArgs": [ "0" ], "MessageId": "TaskEvent.1.0.1.TaskStarted", "Resolution": "None.", "Severity": "OK" }
],
"Name": "Task 0",
"Payload":
{ "HttpHeaders": [ "Host: <IP of the host>", "User-Agent: curl/7.64.0", "Accept: */*", "Content-Length": <length of the content> ], "HttpOperation": "POST", "JsonBody": "null", "TargetUri": "/redfish/v1/ComponentIntegrity/<ID>/Actions/SPDMGetSignedMeasurements" }
,
Step3: Task completion
==============
GET /redfish/v1/TaskService/Tasks/0
{
"@odata.id": "/redfish/v1/TaskService/Tasks/0",
"@odata.type": "#Task.v1_4_3.Task",
"Id": "0",
"Messages": [
{ "@odata.type": "#Message.v1_0_0.Message", "Message": "The task with id 0 has completed.", "MessageArgs": [ "0" ], "MessageId": "TaskEvent.1.0.1.TaskCompleted", "Resolution": "None.", "Severity": "OK" }
],
"Name": "Task 0",
"Payload": {
"HttpHeaders": [
"Host: <Ip address of the host>",
"User-Agent: curl/7.64.0",
"Accept: /",
"Content-Length: <length of the content>",
“Location: "location of the URL which will get the SPDM Signed measurement response eg: /redfish/v1/systems/<id>/signedmesaurements/<id> ”
],
Step 4: GET the SPDM Measurement Data from the URL mentioned in the location header.
=======================================================
GET /redfish/v1/systems/<id>/signedmesaurements/<id
{
"HashingAlgorithm": "TPM_ALG_SHA_384",
"SignedMeasurements": "EeAAARFgAAABCwAAAQEHAIMEAAAAAAECAAAAAAECAAAAAQECAvpTsG+V9Lg==",
"SigningAlgorithm": "TPM_ALG_ECDSA_ECC_NIST_P384",
"Version": "1.1.0"
}
If that makes sense we need to update this example somewhere.
|
|
|
|
Post by mraineri on Sept 26, 2022 12:30:42 GMT
Steps 2 and onward are not correct. For step 2, the client would be performing a GET on the task monitor URI (not the task resource). The Location header in the response for step 1 will contain this URI (the @odata.id property in the body of the response contains the resource URI and not the monitor URI). For step 3, the response body (assuming the client is performing a GET on the task monitor URI) would be the response shown in step 4. We have a sample workflow for tasks in the Redfish User Guide: www.dmtf.org/sites/default/files/standards/documents/DSP2060_1.0.0.pdf (section 11.1). |
|
|
|
Post by ratagupt on Sept 26, 2022 15:25:29 GMT
Thanks Mike, Step2 was to show the task started and Step3 is task completed.
I got it in both the case needs to use the Task monitor URL rather then task URL.
Just for my curiosity what would be the task payload->httpheaders->Location value when the task get completed? will it keep pointing to the task monitor URL?
|
|
|
|
Post by mraineri on Sept 26, 2022 16:16:38 GMT
In the task resource, the "HttpHeaders" property reflects the HTTP headers in the original request that initiated the operation. It will not contain any response information. I think the descriptions need a bit of work since it's not very clear that was the intent.
|
|
|
|
Post by ratagupt on Oct 11, 2022 4:25:45 GMT
@mike: Can an API be synchronous or asynchronous at any moment of time?
What I mean to say that depending on the input, API Implementation can decide whether to go with task based(HTTP 202) versus synchronus(HTTP 200).
eg: Asynchronous
Request : curl -d '{"MeasurementIndices" : [1,3,5,7,11,15,21,25] }' -X POST http://<ip>/redfish/v1/ComponentIntegrity/<ID>/Actions/SPDMGetSignedMeasurements
Response: { "@odata.id": "/redfish/v1/TaskService/Tasks/0", "@odata.type": "#Task.v1_4_3.Task", "Id": "1", "TaskState": "Started", "TaskStatus": "OK" }
Synchronous:
Request : curl -d '{"MeasurementIndices" : [1,3] }' -X POST http://<ip>/redfish/v1/ComponentIntegrity/<ID>/Actions/SPDMGetSignedMeasurements
Response: {
"HashingAlgorithm": "TPM_ALG_SHA_384",
"SignedMeasurements": "EeAAARFgAAABCwAAAQEHAIMEAAAAAAECAAAAAAECAAAAAQECAvpTsG+V9Lg==",
"SigningAlgorithm": "TPM_ALG_ECDSA_ECC_NIST_P384",
"Version": "1.1.0"
}
In the above case, you see that If I request for multiple measurements which the implementation knows that it is going to take long, Go with task based approach otherwise go with synchronous behavior.
I understand need to put this intelligence in the redfish server but what is the guideline from Redfish perspective?
|
|
|
|
Post by mraineri on Oct 11, 2022 13:03:28 GMT
If you can make that type of determination in the service for when to spawn a task or not, you're certainly allowed to do what you're showing. I've typically not seen that though, but that's generally because it's usually a hard thing for a service to determine. Clients are supposed to prepare for either type of outcome.
|
|
