Update path for Port Channel configuration.

[kamalkrbh]

In SONiC 4.2.0,

Using the path

https://{device_ip_list[0]}/restconf/data/sonic-portchannel:sonic-portchannel/PORTCHANNEL_MEMBER/PORTCHANNEL_MEMBER_LIST with the payload

req_body = { "sonic-portchannel:PORTCHANNEL_MEMBER_LIST": [ {"name": "PortChannel101", "ifname": "Ethernet56"}, {"name": "PortChannel101", "ifname": "Ethernet76"}, ] } It responds with 204 Http code. but only one member is added at the end. On further analysis, while adding portchannel member via CLI, I see that one of the interfaces is a VLAN member and can't be added to the PortChannel. REST or gNMI call should also fail in such case but they show a incorrect successful status.

[kamalkrbh]

Use the correct path recorded in log file.

[rahul-1475]

• Using the above path to add members to the port channel successfully added both members.

• For adding VLAN members, we are currently using the exact path that was used in the CLI i.e., https://10.10.229.58/restconf/data/openconfig-interfaces:interfaces/interface={port_channel_name}/openconfig-if-aggregate:aggregation/openconfig-vlan:switched-vlan/config.

• Updating the access VLAN is not reflected and cannot be changed to a new VLAN ID.

• Both trunk valns and access valn can have same vlan id.

• More information is needed on this task.

[kamalkrbh]

@rahul-1475 Port channel notebook has been updated with the following cells. Add/Remove/Get Trunk Member VLAN Add/Remove/Get Access Member VLAN Please refer.

[kamalkrbh]

There are following observations :

• [x] If we try to change the interface mode of a portchannel from "trunk" to "access", it is required to first delete trunk config from port channel, but from "access" to "trunk" restconf path doesn't require to delete "access" configuration. Test if it is the similar case with gNMI as well ? If so we can mitigate this in ORCA i.e. while making a port channel to be a "access" interface we first delete "trunk" config (only if there was any trunk config already.)
• [x] Also while updating access vlan number on a portchannel which is already a in access mode, resconf requires to first delete the access config then apply new config with new vlan. Test if it is the similar case with gNMI? If so we also mitigate the 2 steps into one in ORCA i.e. If user requests to update access vlan number on a portchannel which is in interface mode "access" first delete the access config (only when there is already a access vlan assigned anf interface mode is "access") then apply new config.
• [x] The API should take interface mode (enum) as an input and list of vlans, in case of access mode vlan list will have only one element .

[rahul-1475]

orca_backend pr: https://github.com/STORDIS/orca_backend/pull/54 orca_nw_lib pr: https://github.com/STORDIS/orca_nw_lib/pull/85

[kamalkrbh]

@rahul-1475 , Some chages are requested on the PRs for backend.