Fix poll mode for querying non existing table or key for APPL_DB (#375) #382
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ic-net#375) SONiC telemetry does not behave according to gnmi specifications | **POLL MODE** | **Target doesn't exist** | **Table doesn't exist** | **Key doesn't exist** | **Table gets deleted** | **Key gets deleted** | **Field added** | **Field gets changed** | |---------------------------------|----------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------|---------------------------------|-------------------------------------| | **Official gNMI Spec** | RPC_NOT_FOUND, entire RPC fails | Omit Notification from RPC response, rpc should be open | Omit notification from RPC response, rpc should be open | Delete notifcation includes path | Delete notification includes path | Normal update response | Normal update response | | **SONiC** | RPC_NOT_FOUND, entire RPC fails | RPC stays open and updates work properly. We do send empty notifications which isn't technically part of the official gnmi protocol. | Server fails internally with redis Hget, client is left to hang with no sync response; RPC is left in a bad state with no updates even from good paths. | Empty update notifications. No delete proto | Update notification with remaining keys or just empty update notification. No delete proto | Normal update response | Normal Update response | https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md#3513-the-subscription-message As per gnmi specification regarding missing data, "There is no requirement that the path specified in the message must exist within the current data tree on the server. While the path within the subscription SHOULD be a valid path within the set of schema modules that the target supports, subscribing to any syntactically valid path within such modules MUST be allowed. In the case that a particular path does not (yet) exist, the target MUST NOT close the RPC and instead should continue to monitor for the existence of the path, and transmit telemetry updates should it exist in the future." As per gnmi specification regarding deleted keys/paths, "Where a node within the subscribed paths has been removed, the delete field of the Notification message MUST have the path of the node that has been removed appended to it." If there is missing data, we will not return any failures, but instead we will send sync responses only until data is on the device for polling APPL_DB If data is deleted, we will send a delete notification to tell client that path they are querying is deleted and after send sync responses for polling APPL_DB. UT
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Requires backport of #299 to 202405 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
MS: 32418202
SONiC telemetry does not behave according to gnmi specifications
https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md#3513-the-subscription-message
As per gnmi specification regarding missing data, "There is no requirement that the path specified in the message must exist within the current data tree on the server. While the path within the subscription SHOULD be a valid path within the set of schema modules that the target supports, subscribing to any syntactically valid path within such modules MUST be allowed. In the case that a particular path does not (yet) exist, the target MUST NOT close the RPC and instead should continue to monitor for the existence of the path, and transmit telemetry updates should it exist in the future."
As per gnmi specification regarding deleted keys/paths, "Where a node within the subscribed paths has been removed, the delete field of the Notification message MUST have the path of the node that has been removed appended to it."
If there is missing data, we will not return any failures, but instead we will send sync responses only until data is on the device for polling APPL_DB
If data is deleted, we will send a delete notification to tell client that path they are querying is deleted and after send sync responses for polling APPL_DB.
UT
Why I did it
How I did it
How to verify it
Which release branch to backport (provide reason below if selected)
Description for the changelog
Link to config_db schema for YANG module changes
A picture of a cute animal (not mandatory but encouraged)