Post by danwarzecha on Jan 9, 2024 19:04:58 GMT
Hello,
I am looking to gain a better understanding of the requirements to successfully subscribe to a specific event using Resource type/Origin resource. I understand that all the physical filtering and RESTFUL operations are out of the scope of the Redfish standard. I'm more so wanting to ensure that I understand how and which of the different schema objects were intended to be used. I have be able to successful subscribe and then trigger the Test Event and see the basic notification process, but would like to delve deeper into more useful features that Redfish Event Service has to offer.
I would like to work though an example here to better help my understanding.
Goal in this example, Have a Subscription to the below resource being updated, in other words send an event to the subscriber every time 'ReadingVolts' is updated. If that is even possible to be that specific?
{
"@odata.id": "/redfish/v1/Chassis/chassis/Power#/Voltages/2",
"@odata.type": "#Power.v1_0_0.Voltage",
"LowerThresholdCritical": 85.0,
"LowerThresholdNonCritical": 90.0,
"MaxReadingRange": 300.0,
"MemberId": "2",
"MinReadingRange": 0.0,
"Name": "PSU0 Input Voltage",
"ReadingVolts": 121.625,
"Status": {
"Health": "OK",
"State": "Enabled"
},
"UpperThresholdCritical": 270.0,
"UpperThresholdNonCritical": 250.0
}
To re-iterate, I realize this will not be 'standard' at all to every Redfish implementation. I'm just trying to work though how the different filtering schema objects/properties were intended to be used if the given Redfish implementation did support it.
So first up, would be the 'Event Service' on redfish right? So these things would need to be implemented on Redfish in order for any advanced event filtering to work.
On the Redfish implementation I'm assuming the below list would all need to be enabled:
"SSEFilterPropertiesSupported": {
"EventFormatType": true,
"MessageId": true,
"MetricReportDefinition": true,
"OriginResource": true,
"RegistryPrefix": true,
"ResourceType": true
}
(it's a little confusing, because at the 'EventService' level the above are bools, but at the 'EventDestination' level it uses some of the same above values, but they are lists at that point)
Next there would need to be either ResourceTypes and or OriginResource listed for the subscriber to subscribe to.
1. It is here where I find myself wondering which or maybe both need to be used to achieve the above mentioned goal?
2. Then how specific do the values need to be? For this example, would there need to be a ResourceType called Chassis or could it be as specific as Voltages?
3. Maybe the right idea is that at the 'Event Service' level it simply has the OriginResource set to True? And then it is up to the subscriber to specific the full path as the OriginResources which would be something like /redfish/v1/Chassis/chassis/Power#/Voltages/2?
I think that is it on the Redfish side as far as things that would need to be present and set on the redfish instance in order to successful subscribe to a specific object/property?
Second up would be the 'Event Destination'
The subscriber part seems easier, once the Redfish Instance spells out what is available.
Based on if ResourceTypes or OriginResource was used in the above, then I assume the Subscriber would spell out specifically which Schema or Resource path it wishes to subscribe to when it does the initial POST to Subscriptions.
The final bit, is likely custom RESTFUL operations that are done on the Redfish instance. So on update of the specific resource it would trigger the specific Event to fire, and then it would be a rippling down though the subscribers to see if one cared to be notified? Am I thinking of that correctly? Right now I'm just manually triggering the 'Test Event' so then it does the event action, where as in the example goal I provided I'm counting on an event being triggered when the resource is updated? So I'm thinking, when that specific resource gets updated that an event is then just triggered simultaneously in those lines of code, so this would again be a part of how the Redfish Implementation was done.
Ok, I think that about wraps up my general thoughts and confusion. It may seem like a lot I guess, but really I'm just wondering which Schema objects would need to be present in a Redfish Implementation and then how to properly subscribe to those objects in order to achieve the goal of being able to Subscribe to a Specific Object or thing changing or updating. I'm looking to understand how the Redfish instance would need to be implemented as well as how to interact with it. So understanding both sides of the equation.
Thanks for your help! I have watched the youtube videos, on eventing...so I know for sure I shouldn't be using the 'EventType' object as that is deprecated. I have also looked at the Redfish Mockups online, which help to see how things are generally laid out, just not so much how things work or how different objects/properties are used.
I am looking to gain a better understanding of the requirements to successfully subscribe to a specific event using Resource type/Origin resource. I understand that all the physical filtering and RESTFUL operations are out of the scope of the Redfish standard. I'm more so wanting to ensure that I understand how and which of the different schema objects were intended to be used. I have be able to successful subscribe and then trigger the Test Event and see the basic notification process, but would like to delve deeper into more useful features that Redfish Event Service has to offer.
I would like to work though an example here to better help my understanding.
Goal in this example, Have a Subscription to the below resource being updated, in other words send an event to the subscriber every time 'ReadingVolts' is updated. If that is even possible to be that specific?
{
"@odata.id": "/redfish/v1/Chassis/chassis/Power#/Voltages/2",
"@odata.type": "#Power.v1_0_0.Voltage",
"LowerThresholdCritical": 85.0,
"LowerThresholdNonCritical": 90.0,
"MaxReadingRange": 300.0,
"MemberId": "2",
"MinReadingRange": 0.0,
"Name": "PSU0 Input Voltage",
"ReadingVolts": 121.625,
"Status": {
"Health": "OK",
"State": "Enabled"
},
"UpperThresholdCritical": 270.0,
"UpperThresholdNonCritical": 250.0
}
To re-iterate, I realize this will not be 'standard' at all to every Redfish implementation. I'm just trying to work though how the different filtering schema objects/properties were intended to be used if the given Redfish implementation did support it.
So first up, would be the 'Event Service' on redfish right? So these things would need to be implemented on Redfish in order for any advanced event filtering to work.
On the Redfish implementation I'm assuming the below list would all need to be enabled:
"SSEFilterPropertiesSupported": {
"EventFormatType": true,
"MessageId": true,
"MetricReportDefinition": true,
"OriginResource": true,
"RegistryPrefix": true,
"ResourceType": true
}
(it's a little confusing, because at the 'EventService' level the above are bools, but at the 'EventDestination' level it uses some of the same above values, but they are lists at that point)
Next there would need to be either ResourceTypes and or OriginResource listed for the subscriber to subscribe to.
1. It is here where I find myself wondering which or maybe both need to be used to achieve the above mentioned goal?
2. Then how specific do the values need to be? For this example, would there need to be a ResourceType called Chassis or could it be as specific as Voltages?
3. Maybe the right idea is that at the 'Event Service' level it simply has the OriginResource set to True? And then it is up to the subscriber to specific the full path as the OriginResources which would be something like /redfish/v1/Chassis/chassis/Power#/Voltages/2?
I think that is it on the Redfish side as far as things that would need to be present and set on the redfish instance in order to successful subscribe to a specific object/property?
Second up would be the 'Event Destination'
The subscriber part seems easier, once the Redfish Instance spells out what is available.
Based on if ResourceTypes or OriginResource was used in the above, then I assume the Subscriber would spell out specifically which Schema or Resource path it wishes to subscribe to when it does the initial POST to Subscriptions.
The final bit, is likely custom RESTFUL operations that are done on the Redfish instance. So on update of the specific resource it would trigger the specific Event to fire, and then it would be a rippling down though the subscribers to see if one cared to be notified? Am I thinking of that correctly? Right now I'm just manually triggering the 'Test Event' so then it does the event action, where as in the example goal I provided I'm counting on an event being triggered when the resource is updated? So I'm thinking, when that specific resource gets updated that an event is then just triggered simultaneously in those lines of code, so this would again be a part of how the Redfish Implementation was done.
Ok, I think that about wraps up my general thoughts and confusion. It may seem like a lot I guess, but really I'm just wondering which Schema objects would need to be present in a Redfish Implementation and then how to properly subscribe to those objects in order to achieve the goal of being able to Subscribe to a Specific Object or thing changing or updating. I'm looking to understand how the Redfish instance would need to be implemented as well as how to interact with it. So understanding both sides of the equation.
Thanks for your help! I have watched the youtube videos, on eventing...so I know for sure I shouldn't be using the 'EventType' object as that is deprecated. I have also looked at the Redfish Mockups online, which help to see how things are generally laid out, just not so much how things work or how different objects/properties are used.