-
Notifications
You must be signed in to change notification settings - Fork 539
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[cfgmgr] Fix for STATE_DB Port check logic in cfgmgr daemons #1936
Conversation
Change lgtm, but this would be a working function broken. Do you know which PR introduced the change? |
@Junchao-Mellanox , could you please take a look at this? In #1714, it is not mentioned in description about any STATE_DB update and looks like there are impact on cfgmgrs. |
@prsunny I see this PR is approved by you... Are you waiting for feedback from @Junchao-Mellanox before merging? |
Yes |
*Updated checks for PORT entry in STATE_DB in portmgrd, teammgrd, and intfmgrd to additionally check for presence of "state" attribute.
@qbdwlr , @Junchao-Mellanox , isn't this applicable here as well |
* Updated checks for PORT entry in STATE_DB in vlanmgrd additionally check for presence of "state" attribute. This is to add Vlanmgrd check similar to #1936 Signed-off-by: Sudharsan Dhamal Gopalarathnam <sudharsand@nvidia.com>
* Updated checks for PORT entry in STATE_DB in vlanmgrd additionally check for presence of "state" attribute. This is to add Vlanmgrd check similar to #1936 Signed-off-by: Sudharsan Dhamal Gopalarathnam <sudharsand@nvidia.com>
What I did
Updated checks for PORT entry in STATE_DB in portmgrd, teammgrd, and intfmgrd to additionally check for presence of "state" attribute.
Why I did it
Prior to recent commits for PORT auto-negotiation, 3 daemons in cfgmgr (portmgrd, teammgrd, and intfmgrd) would not allow configuration to proceed for a specific PORT until portsyncd detected the presence of the kernel device (EthernetN) associated with the PORT and created the associated entry for the PORT in the STATE_DB with attribute "state" and value "ok".
With recent commits for PORT auto-negotiation, this logic is now broken due to creation of PORT entry in the STATE_DB by PortsOrch with only "supported_speed" attribute.
The logic in the 3 cfgmgr daemons has been updated to additionally check for the "state" attribute when they detect the presence of the PORT entry in STATE_DB.
How I verified it
SONiC unit-tests and platform tests.
Details if related
N/A