Add gNPSI HLD #2019
Add gNPSI HLD #2019
Conversation
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
|
|
||
|
|
||
| #### 10.1. Unit Test cases | ||
|
|
There was a problem hiding this comment.
Can you add a sample gNPSI client commands?
doc/gnpsi/gnpsi_hld.md
Outdated
| "port": "<port_num>" | ||
| } | ||
| COUNTERS_DB: | ||
| "COUNTERS:GNPSI:<remote_ip>/<port_num>": { |
There was a problem hiding this comment.
See if you can keep last N clients and flush upon feature disable.
|
|
||
|
|
||
|  | ||
|
|
There was a problem hiding this comment.
Is it possible to handle local loopback write internally instead of exposing the internal IPC between hsflowd and gNPSI server to the user?
|
Lines 82 to 89 in dc17649 My reading of the HLD is that there are no close dependencies between sFlow and gNPSI features. gNPSI is a general purpose tunneling service for a local UDP ports (that can be used for sFlow, NetFlow, IPFIX etc) that is part of the gRPC Telemetry set of features. As such, gNPSI doesn’t belong inside the sFlow container as it would unnecessarily couple the two services and make development, testing and maintenance of both services more complicated. Loose coupling through Redis for configuration and a UDP streaming from the sFlow to gNPSI container would cleanly separate what should be independent SONiC features (sFlow / gRPC). |
No description provided.