Skip to main content

POST – Telemetry Service

Request

POST https://{{ip}}/redfish/v1/TelemetryService/Actions/TelemetryService.SubmitTestMetricReport
Content-Type: application/json

Request example

{
"MetricReportName": "Average2",
"GeneratedMetricReportValues": [
{
"MetricId": "Temp_average_reading_Average",
"MetricProperty": "/redfish/v1/Chassis/Self/Thermal#/Temperatures/116_0/ReadingCelsius",
"MetricValue": "23",
"Timestamp": "2019-07-01T06:05:52+00:00"

]
}

Response

  1. The response status is 202 Accepted with the created Task Instance as the response body.

  2. For Error Responses, please refer to Error Response.

{
"@odata.context": "/redfish/v1/$metadata#Task.Task(TaskState,Description,Name,Id)",
"@odata.id": "/redfish/v1/TaskService/Tasks/1",
"@odata.type": "#Task.v1_4_2.Task",
"Description": "Task for TelemetryService SubmitTestMetricReport Action",
"Id": "1",
"Name": "TelemetryService SubmitTestMetricReport Action",
"TaskState": "New"
}

Behavior

  • The limitation applied to this resource is that only 3 concurrent requests can be currently executing for SubmitTestEvent Action, at a given time. To issue an additional request, we need to wait for at least one request to finish from the earlier issued ones and so on.

  • For SubmitTestEvent Action to return 202 Accepted with Task Instance in Response Body, the following programmatic flow comes into the picture:
    1. Validate all Request Body Properties.

      If Error exists, throw 400 Bad Request with corresponding error body. If success, go to Step 2.

    2. Check for the total count of current tasks.

      1. If count_of_current_tasks >= Maximum_Tasks_Limit(i.e. 15), then check for the value of CompletedTaskOverWritePolicy attribute.

      2. If the value of CompletedTaskOverWritePolicy attribute is anything other than "Overwrite", then throw 400 Bad Request with "CreateLimitReachedForResource" Error.

      3. If "Overwrite" is the value of CompletedTaskOverWritePolicy attribute, then check for any older tasks in the states "Completed" or "Cancelled" or "Exception". If so, then delete those tasks and create a Task and return 202 Accepted.

      4. If count_of_current_tasks < Maximum_Tasks_Limit, then create a Task and return 202 Accepted. In this scenario, only one task will be created, irrespective of the number of Active Subscriptions.

      5. This task will show the status of all the Failure/Success Event Destinations.

    3. Check created task.

      1. The User may then give a GET Request periodically to check the status of the created Task based on the Task Instance returned in Step 2.

      2. In the background, the created task will trigger the Task Daemon and it will execute a Lua File and pass the event related data as an argument to the file. The Lua File will run as a separate thread.

    4. Check active subscriptions.

      1. Inside the thread execution, we will get the list of Available Active Subscriptions first.

      2. Then we will get the list of Active Subscriptions who have "Event" as the "EventFormatType".

      3. If there are no Active Subscriptions itself, then the created task will have "NoActiveSubscriptionPresent" Error Message and the "TaskStatus" will be updated as "Warning" and "TaskState" as "Exception" and the thread will terminate.

      4. If there are no Active Subscriptions having "Event" as the "EventFormatType", then the created task will have "NoActiveSubscriptionOfFormatTypeEventPresent" Error Message and the "TaskStatus" will be updated as "Warning" and "TaskState" as "Exception" and the thread will terminate.

      5. If there are Active Subscriptions having "Event" as the "EventFormatType", Frame the Event Notification data and go to Step 5.

    5. Loop the Event Subscribers one by one, do some logical-checks-done-in-event-service-daemon.

      1. If at-least one logical-checks fail, add "SubmitTestEventPreconditionsFailed" Message to the response body and proceed to the next subscriber. If all logical-checks pass, try sending the event to the corresponding event destination.

      2. If Event Notification is delivered to the destination, add "Success" Message to the response body and proceed to the next subscriber.

      3. If Event Notification fails to be delivered to the destination, add the appropriate Message from among "CouldNotEstablishConnection" and "SourceDoesNotSupportProtocol" to the response body and proceed to the next subscriber.

      4. Continue the step until we are done with all the subscribers.

      5. If the Event Notification fails to be delivered to at-least one destination, then update "TaskStatus" as "Critical" and "TaskState" as "Exception".

      6. If the Event Notification is delivered to all destination, then update "TaskStatus" as "OK" and "TaskState" as "Completed".

      7. Finally set the collective response body to the Messages attribute of the created task instance.