Skip to content

Streaming events URL support "not to use cache"#45

Merged
renukamanavalan merged 11 commits intosonic-net:masterfrom
renukamanavalan:statistics
Oct 13, 2022
Merged

Streaming events URL support "not to use cache"#45
renukamanavalan merged 11 commits intosonic-net:masterfrom
renukamanavalan:statistics

Conversation

@renukamanavalan
Copy link
Contributor

Why I did it

Only one gNMI client can use cache at any time.
The external clients that stream events reliably need to use cache.
While an external client is connected, if we need to use some test client (e.g. gnmi_cli), it could be used provided it does not use cache.

How I did it

Added support for a new URL parameter [usecache=false]. This parameter will disable use of cache.

How to verify it

  1. Have no gNMI client
  2. Ensure some events are published (may use events_tool to manually publish)
  3. Run gnmi_cli with [usecache=false]
  4. Note, it does not receive/spew any events from past.
  5. Publish some events (may use events_tool)
  6. See the client receive these
  7. Now run a client with cache use not disabled
  8. Note, it receives all events including those from step 2

Which release branch to backport (provide reason below if selected)

  • 201811
  • 201911
  • 202006
  • 202012
  • 202106
  • 202111

Description for the changelog

Link to config_db schema for YANG module changes

A picture of a cute animal (not mandatory but encouraged)

renukamanavalan and others added 10 commits October 5, 2022 23:43
When configured via args:
    1) Write responses only to a o/p file instead of stdout.
    2) For on change events, filter for a specific event.
    3) Exit upon receiving N responses.
    4) Exit upon timeout.

The above would help use gnmi_cli as tool in scripting environment that does testing.
* syntax

* Update gnmi_cli
When configured via args:
    1) Write responses only to a o/p file instead of stdout.
    2) For on change events, filter for a specific event.
    3) Exit upon receiving N responses.
    4) Exit upon timeout.

The above would help use gnmi_cli as tool in scripting environment that does testing.
…e" in Query URL.

This is useful as only one events client can use cahe.
The only client that uses cache today is gNMI events-client.
So when we use gnmi_cli, which also uses events-client, have the ability to disable  cache.
This way, while GWS service is connected, we could still use gnmi_cli w/o any impact to GWS service.
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;The SONiC switch does offline cache when gNMI client is down.<br/>
&nbsp;&nbsp;&nbsp;&nbsp;The cached events are delivered upon nest gNMI connection<br/>
&nbsp;&nbsp;&nbsp;&nbsp;Only one client should use the cache service<br/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How to guarantee this limitation?
If two clients use the cache service, what will happen?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Limitation by design.
Trade off between code complexity in supporting multiple clients with cache vs practical use case.
In practice, there is only one client streaming out.
This is added to enable test tools to function w/o disturbing the main service.
To answer your question: If multiple use cache, of course first come first served. The cache will go to one or other.

@renukamanavalan renukamanavalan merged commit 176c385 into sonic-net:master Oct 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants