Don't create the members@ array in config_db for PC when reading from minigraph#13660
Conversation
… minigraph When loading from minigraph, for port channels, don't create the members@ array in config_db in the PORTCHANNEL table. This is no longer needed or used. In addition, when adding a port channel member from the CLI, that member doesn't get added into the members@ array, resulting in a bit of inconsistency. This gets rid of that inconsistency. Fixes sonic-net#11873. Signed-off-by: Saikrishna Arcot <[email protected]>
Signed-off-by: Saikrishna Arcot <[email protected]>
|
/azpw run Azure.sonic-buildimage |
|
/AzurePipelines run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| intfs_inpc.append(pcmbr_list[i]) | ||
| pc_members[(pcintfname, pcmbr_list[i])] = {} | ||
| if pcintf.find(str(QName(ns, "Fallback"))) != None: | ||
| pcs[pcintfname] = {'members': pcmbr_list, 'fallback': pcintf.find(str(QName(ns, "Fallback"))).text, 'min_links': str(int(math.ceil(len() * 0.75))), 'lacp_key': 'auto'} |
There was a problem hiding this comment.
Do you want to update src/sonic-yang-models/yang-models/sonic-portchannel.yang at the same time?
@ganglyu for vis. #Closed
There was a problem hiding this comment.
Yes, removed from the yang file.
Signed-off-by: Saikrishna Arcot <[email protected]>
|
There may have many test file need to be updated in src/sonic-yang* |
Signed-off-by: Saikrishna Arcot <[email protected]>
Signed-off-by: Saikrishna Arcot <[email protected]>
Signed-off-by: Saikrishna Arcot <[email protected]> Description of PR Summary: Fixes sonic-net/sonic-buildimage#11873 sonic-net/sonic-buildimage#11873 Approach What is the motivation for this PR? The members entry in the PORTCHANNEL table has been removed. Switch to using PORTCHANNEL_MEMBERS instead. Related to sonic-net/sonic-buildimage#13660 sonic-net/sonic-buildimage#13660
Signed-off-by: Saikrishna Arcot <[email protected]> Description of PR Summary: Fixes sonic-net/sonic-buildimage#11873 sonic-net/sonic-buildimage#11873 Approach What is the motivation for this PR? The members entry in the PORTCHANNEL table has been removed. Switch to using PORTCHANNEL_MEMBERS instead. Related to sonic-net/sonic-buildimage#13660 sonic-net/sonic-buildimage#13660
|
@saiarcot895 PR conflicts with 202205 branch |
… minigraph (sonic-net#13660) Fixes sonic-net#11873. #### Why I did it When loading from minigraph, for port channels, don't create the members@ array in config_db in the PORTCHANNEL table. This is no longer needed or used. In addition, when adding a port channel member from the CLI, that member doesn't get added into the members@ array, resulting in a bit of inconsistency. This gets rid of that inconsistency.
|
Cherry-pick PR to 202211: #14343 |
… minigraph (#13660) Fixes #11873. #### Why I did it When loading from minigraph, for port channels, don't create the members@ array in config_db in the PORTCHANNEL table. This is no longer needed or used. In addition, when adding a port channel member from the CLI, that member doesn't get added into the members@ array, resulting in a bit of inconsistency. This gets rid of that inconsistency.
KeyError: 'members' is introduced by this PR sonic-net/sonic-buildimage#13660. In original config, we use PORTCHANNEL, now it is changed to PORTCHANNEL_MEMBER. So, the relevant test should be updated accordingly. Test log: oports = [] for ifname in ifnames: if po.has_key(ifname): oports.append([str(mg_facts['minigraph_ptf_indices'][x]) for x in po[ifname]['members']]) E KeyError: 'members' What is the motivation for this PR? Fix test_inner_harhing issue How did you do it? PORTCHANNEL is changed to PORTCHANNEL_MEMBER How did you verify/test it? Run test_inner_hashing
KeyError: 'members' is introduced by this PR sonic-net/sonic-buildimage#13660. In original config, we use PORTCHANNEL, now it is changed to PORTCHANNEL_MEMBER. So, the relevant test should be updated accordingly. Test log: oports = [] for ifname in ifnames: if po.has_key(ifname): oports.append([str(mg_facts['minigraph_ptf_indices'][x]) for x in po[ifname]['members']]) E KeyError: 'members' What is the motivation for this PR? Fix test_inner_harhing issue How did you do it? PORTCHANNEL is changed to PORTCHANNEL_MEMBER How did you verify/test it? Run test_inner_hashing
Related work items: sonic-net#276, sonic-net#305, sonic-net#332, sonic-net#338, sonic-net#339, sonic-net#1188, sonic-net#1192, sonic-net#1197, sonic-net#1206, sonic-net#1685, sonic-net#1690, sonic-net#1696, sonic-net#1699, sonic-net#1709, sonic-net#1727, sonic-net#1737, sonic-net#1741, sonic-net#1742, sonic-net#2511, sonic-net#2512, sonic-net#2532, sonic-net#2559, sonic-net#2626, sonic-net#2638, sonic-net#2645, sonic-net#2649, sonic-net#2660, sonic-net#2669, sonic-net#2670, sonic-net#2678, sonic-net#10084, sonic-net#11442, sonic-net#11873, sonic-net#12047, sonic-net#12110, sonic-net#12207, sonic-net#12529, sonic-net#12678, sonic-net#13235, sonic-net#13287, sonic-net#13372, sonic-net#13395, sonic-net#13456, sonic-net#13497, sonic-net#13522, sonic-net#13545, sonic-net#13547, sonic-net#13552, sonic-net#13569, sonic-net#13572, sonic-net#13578, sonic-net#13591, sonic-net#13611, sonic-net#13647, sonic-net#13649, sonic-net#13660, sonic-net#13710, sonic-net#13716, sonic-net#13724, sonic-net#13726, sonic-net#13732, sonic-net#13735, sonic-net#13739, sonic-net#13757, sonic-net#13786, sonic-net#13792, sonic-net#13800, sonic-net#13801, sonic-net#13802, sonic-net#13805, sonic-net#13806, sonic-net#13812, sonic-net#13814, sonic-net#13822, sonic-net#13831, sonic-net#13834, sonic-net#13847, sonic-net#13870, sonic-net#13882, sonic-net#13884, sonic-net#13885, sonic-net#13894, sonic-net#13895, sonic-net#13926, sonic-net#13932, sonic-net#13935, sonic-net#13942, sonic-net#13951, sonic-net#13953, sonic-net#13964
|
Hi @saiarcot895, I am seeing internal back plane port channels in 'show interface portchannel'. It used to display only front-end port channels and '-d all' used to display all, as expected. Could this behavior change be due to the changes in this PR? |
|
@anamehra , please file an issue for this? Thanks. |
|
@saiarcot895 , @yxieca - is this PR indeed needed in 202205? please share more info, thanks |
In `show interface portchannel` and `show ip route`, backend port channels and routes were being displayed. This is due to changes in sonic-net#13660. Fix these issues by switching to reading from PORTCHANNEL_MEMBERS table instead. Fixes sonic-net#14459. Signed-off-by: Saikrishna Arcot <[email protected]>
|
@rlhui This PR was to fix an inconsistency in how port channel members were specified in config_db.json. On regular T0 and T1 KVM devices, it appeared that there weren't any users of the I requested it for 202205 and 202211 since it is a bug fix (there could be different port channel members returned depending on which table is used) and it didn't appear to cause any breakages, but because I didn't check the hardware test cases and I didn't check multi-asic, I didn't notice there would be breakages there. |
* Fix backend port channels and routes being displayed In `show interface portchannel` and `show ip route`, backend port channels and routes were being displayed. This is due to changes in #13660. Fix these issues by switching to reading from PORTCHANNEL_MEMBERS table instead. Fixes #14459. * Replace table name with constant Signed-off-by: Saikrishna Arcot <[email protected]>
* Fix backend port channels and routes being displayed In `show interface portchannel` and `show ip route`, backend port channels and routes were being displayed. This is due to changes in sonic-net#13660. Fix these issues by switching to reading from PORTCHANNEL_MEMBERS table instead. Fixes sonic-net#14459. * Replace table name with constant Signed-off-by: Saikrishna Arcot <[email protected]>
Fixes #11873.
Signed-off-by: Saikrishna Arcot [email protected]
Why I did it
When loading from minigraph, for port channels, don't create the members@ array in config_db in the PORTCHANNEL table. This is no longer needed or used.
In addition, when adding a port channel member from the CLI, that member doesn't get added into the members@ array, resulting in a bit of inconsistency. This gets rid of that inconsistency.
How I did it
How to verify it
Which release branch to backport (provide reason below if selected)
Description for the changelog
Ensure to add label/tag for the feature raised. example - PR#2174 under sonic-utilities repo. where, Generic Config and Update feature has been labelled as GCU.
Link to config_db schema for YANG module changes
A picture of a cute animal (not mandatory but encouraged)