[show priority-group drop counters] Remove backup with cached PG drop counters after 'config reload'

[ayurkiv-nvda]

Signed-off-by: Andriy Yurkiv ayurkiv@nvidia.com

What I did

Explanation how show/clear counters works:

• Suppose we got from SDK some count of dropped packets for priority group (№3) per interface (Ehernet4). (for example Ethernet4 PG-3 123 packets)
• Stats can be shown via show priority-group drop counters
  Then we run sonic-clear priority-group drop counters. This command will save data "Ethernet4 PG-3 123 packets" to backup. It saved in /tmp/dropstat-{user_id} folder
• When we run show priority-group drop counters again, script will take data from SDK and data saved from backup. In backup it will find 123. In SDK it may still be number 123 for Ethernet4 (like in backup) or bigger (for example 126.)
  Our sonic-clear priority-group drop counters command does not change anything in SDK. It just show difference beetwen SDK data and last saved data.
  So if in SDK data is 123, show priority-group drop counters will show 0 (123 minus 123) - data is cleared
  If in SDK data is bigger than saved 124, or higher show priority-group drop counters will show 1 (124 minus 123)

FIX
After config reload all counters drop counters data retrieved from SDK become cleared. All counters become zeros.
In this case show priority-group drop counters will show -123 ( 0 (from SDK) minus 123 (saved backup))
So we don't need backup after config reload

How I did it

remove /tmp/dropstat-{user_id} folders with counters backup

How to verify it

• provoke PG dropped packets (Use QoS test with prf32 topo and RPC image)
• check that counters increased show priority-group drop counters
• clear counter via sonic-clear priority-group drop counters
• run sudo config reload -y
• check that counters are zeros show priority-group drop counters

Previous command output (if the output of a command-line utility has changed)

       Port    PG0    PG1    PG2    PG3    PG4    PG5    PG6    PG7
-----------  -----  -----  -----  -----  -----  -----  -----  -----
  Ethernet0      0      0      0      0      0      0      0      0
  Ethernet4      0      0      0   -123      0      0      0      0

New command output (if the output of a command-line utility has changed)

       Port    PG0    PG1    PG2    PG3    PG4    PG5    PG6    PG7
-----------  -----  -----  -----  -----  -----  -----  -----  -----
  Ethernet0      0      0      0      0      0      0      0      0
  Ethernet4      0      0      0      0      0      0      0      0

[liat-grozovik]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[liat-grozovik]

@ayurkiv-nvda please add unit test to catch the issue which will work now with the fix. if i am not mistaken config reload cannot be used in the unittest infra so please consider simulation the behaviour without a config reload.

[neethajohn]

Will review once there is a testcase for this

[liat-grozovik]

Will review once there is a testcase for this

@neethajohn there is no infra for unit test for config reload. this was also discussed on other PRs related to changes in config reload. Do you have other suggestion?

[neethajohn]

Will review once there is a testcase for this

@neethajohn there is no infra for unit test for config reload. this was also discussed on other PRs related to changes in config reload. Do you have other suggestion?

@ayurkiv-nvda, can you explore if you could use something similar to this
--dry-run: https://github.com/Azure/sonic-utilities/blob/master/config/main.py#L1985
Sample test: https://github.com/Azure/sonic-utilities/blob/master/tests/config_test.py#L67

[ayurkiv-nvda]

@ayurkiv-nvda please add unit test to catch the issue which will work now with the fix. if i am not mistaken config reload cannot be used in the unittest infra so please consider simulation the behaviour without a config reload.

Done

[ayurkiv-nvda]

Will review once there is a testcase for this

Done