Many Thanks for the response, Lajos. We see this issue particularly on the OVN setup deployed from RedHat. We are using “Red Hat OpenStack Platform release 17.1.1 (Wallaby)”. I believe the below setup is OVS based, in which we were also able to see the bridge name in the dictionary. This is specific to OVN setup. Also please let us know the details about the SDK you have tested. [stack@chndirector ~]$ cat /etc/rhosp-release Red Hat OpenStack Platform release 17.1.1 (Wallaby) Adding @Sivakumar Vedachalam<mailto:sivakumar.vedachalam@gigamon.com>. Regards, Mahudees From: Lajos Katona <katonalala@gmail.com> Date: Monday, 4 December 2023 at 2:05 PM To: Mahudeeswaran Palanisamy <mahudeeswaran.palanisamy@gigamon.com> Cc: openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> Subject: Re: [Neutron] - Getting bridge_name of the port from Java sdk Hi, The patch you referenced was not removing the bridge_name from the binding: vif_details dct actually. I checked in a fresh deployment and the api-ref also and the bridge_name is in the above dict: https: //docs. openstack. org/api-ref/network/v2/index. html#show-port-binding-of-a-port$ Hi, The patch you referenced was not removing the bridge_name from the binding:vif_details dct actually. I checked in a fresh deployment and the api-ref also and the bridge_name is in the above dict: https://docs.openstack.org/api-ref/network/v2/index.html#show-port-binding-of-a-port<https://urldefense.com/v3/__https:/docs.openstack.org/api-ref/network/v2/index.html*show-port-binding-of-a-port__;Iw!!NlDm5TXp!_O5Wod-zjh2Q7Bu-xvid-e2pe9nNGZWX_iLgZ_A-XoLsYoxZ-npG3kPVBVihY8adLdmXzXYb1mzg4ldCLI9-Fl6WI0m9plA$> $ openstack port show ef304f9c-3945-4cd8-bce7-36503196c94f -c binding_vif_details +---------------------+---------------------------------------------------------------------------------------------------------------------------------------------+ | Field | Value | +---------------------+---------------------------------------------------------------------------------------------------------------------------------------------+ | binding_vif_details | bound_drivers.0='openvswitch', bridge_name='br-int', connectivity='l2', datapath_type='system', ovs_hybrid_plug='False', port_filter='True' | +---------------------+---------------------------------------------------------------------------------------------------------------------------------------------+ Could you please give more help what is missing exactly? I am not familiar with java_sdk. I tested with openstcksdk and the bridge name is as expected in the port's binding:vif_details dict. Best wishes. Lajos Mahudeeswaran Palanisamy <mahudeeswaran.palanisamy@gigamon.com<mailto:mahudeeswaran.palanisamy@gigamon.com>> ezt írta (időpont: 2023. dec. 1., P, 18:13): Hi All, Looks like as part of below commit, bridge_name info has been removed from port binding vif_details dictionary. Is there any way that we can get the bridge_name info of a port? As far as checked we can get this info by checking if port UUID is part of “ports” array in “sudo ovs-vsctl list br” output. But there is no equivalent way to get from Java SDK. https://github.com/openstack/neutron/commit/569bafbbd5f90a458d781f1e49f099f96c363683#diff-3fb0e47430c01037fddef45c2ce7314f50a3df5ac41dbd604f9581d90f2985bb<https://urldefense.com/v3/__https:/github.com/openstack/neutron/commit/569bafbbd5f90a458d781f1e49f099f96c363683*diff-3fb0e47430c01037fddef45c2ce7314f50a3df5ac41dbd604f9581d90f2985bb__;Iw!!NlDm5TXp!_O5Wod-zjh2Q7Bu-xvid-e2pe9nNGZWX_iLgZ_A-XoLsYoxZ-npG3kPVBVihY8adLdmXzXYb1mzg4ldCLI9-Fl6WY0q_Tlw$> Thanks, Mahudees This message may contain confidential and privileged information. If it has been sent to you in error, please reply to advise the sender of the error and then immediately delete it. If you are not the intended recipient, do not read, copy, disclose or otherwise use this message. The sender disclaims any liability for such unauthorized use. NOTE that all incoming emails sent to Gigamon email accounts will be archived and may be scanned by us and/or by external service providers to detect and prevent threats to our systems, investigate illegal or inappropriate behavior, and/or eliminate unsolicited promotional emails (“spam”).