|
|
Post by ginugeorge on Dec 15, 2020 7:40:12 GMT
I am having a clarification related to an attribute "ReportActions" which is available under the MetricReportDefinitions Resource.
As per reference to the metadata file MetricReportDefinition_v1.xml, "ReportActions" attribute denotes the set of actions to perform when the metric report is generated and the allowed values are -
LogToMetricReportsCollection - When a metric report is scheduled to be generated, the service shall record the occurrence to the metric report collection found under the Telemetry Service. The Service shall update the metric report collection based on the setting of the ReportUpdates property.
RedfishEvent - When a metric report is scheduled to be generated, the service shall send an event of the MetricReport type to subscribers that the Event Subscription collection in the Event Service describes.
Now when we consider the value "LogToMetricReportsCollection" for the ReportActions attribute, there is an upper limit specified by the MaxReports attribute under the TelemetryService Resource(wrt the metadata file TelemetryService_v1.xml). Once the MetricReports Collection reaches this MaxReports limit, the service shall no longer record the report occurrence to the MetricReports collection.
Whereas, if we consider the value "RedfishEvent" for the ReportActions attribute, there is no such limit enforced and the service shall keep sending events of the MetricReport type to active subscribers.
Should this be the expected behaviour ?
or
Once the MetricReports Collection reaches this MaxReports limit, the service should neither record the occurrence to the MetricReports collection nor send any events of the MetricReport type ?
Please suggest your inputs.
|
|
|
|
Post by jautor on Dec 16, 2020 4:52:30 GMT
Now when we consider the value "LogToMetricReportsCollection" for the ReportActions attribute, there is an upper limit specified by the MaxReports attribute under the TelemetryService Resource(wrt the metadata file TelemetryService_v1.xml). Once the MetricReports Collection reaches this MaxReports limit, the service shall no longer record the report occurrence to the MetricReports collection. Whereas, if we consider the value "RedfishEvent" for the ReportActions attribute, there is no such limit enforced and the service shall keep sending events of the MetricReport type to active subscribers. Should this be the expected behaviour ?
Yes, that is the expected behavior. Because a Redfish Service is expected to be implemented on devices with limited memory, the "MaxReports" property allows the service to indicate that limited memory may be available for storage of metric reports. (Note that a service implementation with ample local storage could set this number to an arbitrary large number, like 10000) In addition, a "new" metric report may replace an older one if the "max" has been reached, so this can still result in new data being stored. But since generating a Redfish Event doesn't consume local storage resources (on the service end), there is no reason to limit the number of events that can be produced. Jeff |
|
|
|
Post by ginugeorge on May 7, 2021 13:47:20 GMT
Hi Jeff,
I am having a clarification over here. Suppose we create a "MetricReportDefinition" with the below mentioned Temperature Sensors under the "MetricProperties" attribute and "ReportUpdates" attribute has value "AppendWrapsWhenFull" and "ReportActions" attribute has value "RedfishEvent"(i.e. When a metric report is scheduled to be generated, the service shall send an event of the MetricReport type).
"/redfish/v1/Chassis/Self/Thermal#/Temperatures/1/ReadingCelsius",
"/redfish/v1/Chassis/Self/Thermal#/Temperatures/2/ReadingCelsius"
Consider, a Metric Report M1 is generated at time t1 and sent as a Metric Report Event.
Suppose at time t2, another Metric Report M2 is generated and should be sent as a Metric Report Event. So the Metric Report Event to be sent at time t2 should include the older Temperature Sensor values generated at time t1 or it should send only the newer Temperature Sensor values generated at time t2 ?
In other words, the Metric Report generated should send all the Sensor values from the time the MetricReportDefinition was created or it should send only the latest sensor values ?
If we need to send all the Sensor values from the time the MetricReportDefinition was created, then with passage of time, the amount of Sensor data sent to the destination over http/https protocol will increase at a brisk rate. Please suggest.
Regards,
Ginu George
|
|
|
|
Post by mraineri on May 7, 2021 17:39:20 GMT
That's correct; in that type of configuration, you'll be sending historic data. There are use cases where a client wants to get a report with historic data. However, in cases where that overhead is concerning, then the client should be configuring the MetricReportDefinition to create a new metric report rather than appending an existing one.
|
|
|
|
Post by ginugeorge on May 10, 2021 10:08:56 GMT
Hi jautor mraineri On the basis of our earlier discussions, I have created the below logic table. The main aim of this discussion is to decide when we need to Send Metric Report Events and Stop Sending Metric Report Events.Please let us know if this design would adhere to the DMTF Redfish Spec or we need to bring about any changes :
| Report Updates | When ReportActions is LogToMetricReportsCollection |
When ReportActions is RedfishEvent
| | Overwrite | Overwrite the sensor data over and again in a MetricReport. |
Overwrite the sensor data over and again in a MetricReport. No Overhead created with passage of time. Continuously Send Events.
| | AppendStopsWhenFull |
Sensor data appended in a MetricReport, with AppendLimit at 200. Stop appending Sensor data to Metric Report once AppendLimit is reached.
|
Sensor data appended in a MetricReport, with AppendLimit at 200. Stop appending Sensor data and Stop sending Events once AppendLimit reached. Overhead can happen with passage of time if we maintain historic data of sensors and continue sending events.
| | AppendWrapsWhenFull |
Sensor data appended in a MetricReport, with AppendLimit at 200. Wraps appending Sensor data to Metric Report once AppendLimit is reached.
|
Sensor data appended in a MetricReport, with AppendLimit at 200. Wraps appending Sensor data to Metric Report once AppendLimit is reached. No Overhead created with passage of time. Continuously Send Events.
| | NewReport |
New MetricReport generated at each scheduled interval. Stop creating New Reports, once MaxReports limit is reached.
| New MetricReport generated at each scheduled interval. Continue creating New Reports and Continuously Send Events, even after MaxReports limit is reached. No Overhead created with passage of time.
|
Regards, Ginu George |
|
|
|
Post by mraineri on May 18, 2021 18:47:12 GMT
That table looks correct in terms of describing the behavior for each of those actions when only one action is configured. One thing to keep in mind though is the standard does allow for MetricReportDefinition to have multiple ReportActions configured simultaneously. So, if that's something you plan to support, then you would also need to think of how to combine the two columns if configured for both actions.
|
|
|
|
Post by ginugeorge on May 25, 2021 5:40:48 GMT
That table looks correct in terms of describing the behavior for each of those actions when only one action is configured. One thing to keep in mind though is the standard does allow for MetricReportDefinition to have multiple ReportActions configured simultaneously. So, if that's something you plan to support, then you would also need to think of how to combine the two columns if configured for both actions. ![]() Hi mraineri , As per our current design implementation in the stack, below mentioned is the list of supported and unsupported scenarios : | ReportUpdates | When ReportActions is [LogToMetricReportsCollection] | When ReportActions is [RedfishEvent] | When ReportActions is [RedfishEvent, LogToMetricReportsCollection] |
Overwrite
| Supported | Not Supported | Supported |
AppendWrapsWhenFull
| Supported | Not Supported | Supported |
AppendStopsWhenFull
| Supported | Not Supported | Supported |
NewReport
| Supported | Not Supported | Supported |
Please let us know if we need to do any design changes in the above mentioned table or we can go ahead with the current design.Regards, Ginu George |
|
|
|
Post by mraineri on May 25, 2021 12:51:15 GMT
That's entirely up to your design for what you want to support. With the exception of mandatory properties and other mandatory behavior, we can't tell you what you need to support.
|
|
