[action] [PR:16213] [chassis] Chassis DB cleanup when asic comes up #16417
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.
Why I did it
In an operational system, after some configuration is changed (that involves line cards generating entries to chassis db), if config reload or system reboot is done without saving the new configuration changes and when system comes up, entries created by the new config are still present in the chassis db and hence the corresponding voq system entries (such as system interface, system neighbor and so on ) in all other line cards. These stale entries may affect the accuracy of the current entries and hence the intended operation of chassis. To fix this, we cleanup the chassis db when the an asic comes up. The chassis db is cleaned up for entries created by the asic that is coming up.
Work item tracking
N/A
How I did it
Cleanup the entries from the following tables in chassis app db in redis_chassis server in the supervisor
(1) SYSTEM_NEIGH
(2) SYSTEM_INTERFACE
(3) SYSTEM_LAG_MEMBER_TABLE
(4) SYSTEM_LAG_TABLE
As part of the clean up only those entries created by the asic that is coming up are deleted. The LAG IDs used by the asics are also de-allocated from SYSTEM_LAG_ID_TABLE and SYSTEM_LAG_ID_SET
How to verify it
Which release branch to backport (provide reason below if selected)
N/A
Tested branch (Please provide the tested image version)
master
Description for the changelog
Link to config_db schema for YANG module changes
None
A picture of a cute animal (not mandatory but encouraged)