You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The documentation within v0.10.0 doesn't currently define precisly for which qosStatus changes a developer can expect to receive a notification, see the description below (and which notifications must be implemented by an QoD API provider).
The discussion topic (see below) suggested to send notifications for all changes of the status of the QoS Session resources, including the initial entering of "available" and the ones induced by API calls by the API consumer (e.g. delete of the QoS session). This behaviour was agreed within the QoD call of Dec 15th.
Expected behavior
The documentation describes the expected behaviour. Test cases are defined for all qosStatus changes.
Originally posted by shilpa-padgaonkar December 12, 2023
As far as I can understand, if response to create session leads to qosStatus "requested", then the developer can later receive the notification, qosStatus "available". However if the create session response leads directly to qosStatus "available", the notification with status "available" will be skipped. Similarly, before explicit delete session or delete session due to timer expiry, there is no notification sent as qosStatus "unavailable". Is this understanding correct?
If yes, what is the thought around always sending notifications whenever qosStatus becomes available or unavailable (due to whatever conditions).
The text was updated successfully, but these errors were encountered:
hdamker
changed the title
Send notifications for all status changes
Send notifications for all qosStatus changes
Jan 11, 2024
Problem description
The documentation within v0.10.0 doesn't currently define precisly for which qosStatus changes a developer can expect to receive a notification, see the description below (and which notifications must be implemented by an QoD API provider).
The discussion topic (see below) suggested to send notifications for all changes of the status of the QoS Session resources, including the initial entering of "available" and the ones induced by API calls by the API consumer (e.g. delete of the QoS session). This behaviour was agreed within the QoD call of Dec 15th.
Expected behavior
The documentation describes the expected behaviour. Test cases are defined for all qosStatus changes.
Alternative solution
Additional context
Discussed in #242
Originally posted by shilpa-padgaonkar December 12, 2023
As far as I can understand, if response to create session leads to qosStatus "requested", then the developer can later receive the notification, qosStatus "available". However if the create session response leads directly to qosStatus "available", the notification with status "available" will be skipped. Similarly, before explicit delete session or delete session due to timer expiry, there is no notification sent as qosStatus "unavailable". Is this understanding correct?
If yes, what is the thought around always sending notifications whenever qosStatus becomes available or unavailable (due to whatever conditions).
The text was updated successfully, but these errors were encountered: