Location header between task and CollectDiagnosticData actio

shawn
Minnow

Posts: 16

Location header between task and CollectDiagnosticData actio Nov 24, 2021 9:32:17 GMT

Quote

Post by shawn on Nov 24, 2021 9:32:17 GMT

Hi all,

I have a question about the Location response header when I issue the LogService.CollectDiagnosticData action. When I issue LogService.CollectDiagnosticData action, it should collect data and I assume it will take a long time so it would be an asynchronized operation.

According to Redfish spec, an asynchronized operation should response HTTP 202 Accepted status code with a Location header set to the URI of a task monitor when the processing of the request requires additional time to be completed.

On the other hand, according to the description of CollectDiagnosticData action in LogService_v1.xml, it says the `Location` header in the response shall contain a URI to a resource of type LogEntry that contains the diagnostic data.

However, according to www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 , it seems we could only have a single Location header in a response. Is it ok to have 2 Location response headers, one for task monitor and the other points to the location of a diagnostic data? If we can't, is there a way to present both information of task and the LogEntry resource?

Many Thanks,
Shawn Weng

Last Edit: Nov 24, 2021 9:35:58 GMT by shawn

jautor
Administrator

Posts: 519

Location header between task and CollectDiagnosticData actio Nov 24, 2021 18:25:36 GMT

Quote

Post by jautor on Nov 24, 2021 18:25:36 GMT

Hi Shawn,

The intent was that since the diagnostic data is stored as a non-Redfish resource (a binary blob), and the Action will create a LogEntry instance, we have the Location header pointing to that LogEntry. The creation of a LogEntry keeps the Action consistent with the service-created diagnostic data - so that the data is retrieved in a consistent manner regardless of who initiated the collection.

The Task Monitor question is a good one that we should discuss, although in this case the LogEntry instance could be monitored to get the same results. The LogEntry should be created immediately, but the AdditionalDataURI property should not appear until the diagnostic data has been collected and can be accessed.

The primary use case we considered is a system crash - an Event would be sent immediately and linked to a LogEntry (pretty obvious that a crash should generate a log entry), and that entry may get updated some time later to include the crash dump data.

And I agree that even if it were allowed by the RFC, having multiple Location headers won't help as no client is going to expect or process those...

Jeff

shawn
Minnow

Posts: 16

Location header between task and CollectDiagnosticData actio Nov 25, 2021 1:49:18 GMT

Quote

Post by shawn on Nov 25, 2021 1:49:18 GMT

Thanks Jeff for the quickly reply.

Yeah it's reasonable to get some automatically generated blob data in a LogEntry when a system crash or something so a user could use the data to analyze it. However, if we put an action there, that means a user could see the system usages by manual. In that case it seems confusing to a user or a vendor with the same logic as others. But I do think the LogService.CollectDiagnosticData action is useful so that a user could able to get some information anytime.

Thanks for being open to discuss the flow of Task Monitor and LogService.CollectDiagnosticData action. If there's any further ideas or conclusion, please let us know.