Hi Vikrant, Please note that you won't see the metadata namespace getting created right after creating a network. The namespace will be present only when necessary; ie., when a port is bound to a chassis and then the metadata agent will detect that condition and create/provision the metadata namespace accordingly *in that chassis*.
So for you to be able to use this namespace for debugging, you would need a VM running on that node (or bind a port manually to it through the iface-id external_id). Cheers, Daniel On Tue, Sep 19, 2017 at 10:06 AM, Numan Siddique <nusid...@redhat.com> wrote: > > Hi Vikrant, > > Please see this link - https://gist.github.com/russ > ellb/4ab0a9641f12f8ac66fdd6822ee7789e and grep for "add_phys_port". > > Can you see what is the value of "ovn_metadata_enabled" in the file > /etc/neutron/plugins/ml2/ml2_conf.ini. > If it is false, then please change it to true and restart the > neutron-server. When you create a new network, you should see a metadata > namespace getting created. > > > Thanks > Numan > > > On Tue, Sep 19, 2017 at 9:32 AM, Vikrant Aggarwal <ervikran...@gmail.com> > wrote: > >> Thanks for your reply Russell. >> >> I installed devstack with latest development releases but I don't see the >> namespace created with latest version also. >> >> ~~~ >> >> [stack@devstack-centos-controller devstack]$ grep -i ovn local.conf | >> grep -v "#" >> enable_plugin networking-ovn https://git.openstack.org/open >> stack/networking-ovn >> enable_service ovn-northd >> enable_service ovn-controller >> enable_service networking-ovn-metadata-agent >> >> [stack@devstack-centos-controller devstack]$ neutron net-list >> neutron CLI is deprecated and will be removed in the future. Use >> openstack CLI instead. >> +--------------------------------------+-----------+-------- >> --------------------------------------------------+ >> | id | name | >> subnets | >> +--------------------------------------+-----------+-------- >> --------------------------------------------------+ >> | 786530e0-775b-482c-8149-c6e751c188da | internal1 | >> dc4961f7-0be3-46be-a545-da7e3a9add8c 10.10.10.0/24 | >> | 823cab04-68ea-4d02-843d-ab420e2b0709 | private | >> 00893897-44b3-42e6-9b2d-568568fae221 fde5:d829:f076::/64 | >> | | | >> 10b1f798-729c-4329-ae0a-65946fee80e4 10.0.0.0/26 | >> | e1ddda3d-eab5-46a9-a880-15f4eab0360c | public | >> b785fc74-ee29-4d0d-bd1f-234337528024 | >> | | | >> d49dc742-9709-4e3b-8a45-68333b7af8b1 | >> +--------------------------------------+-----------+-------- >> --------------------------------------------------+ >> >> [stack@devstack-centos-controller devstack]$ ip netns list >> [stack@devstack-centos-controller devstack]$ >> ~~~ >> >> Can you please share the steps if you have them handy. >> >> Thanks & Regards, >> Vikrant Aggarwal >> >> >> On Tue, Sep 19, 2017 at 1:51 AM, Russell Bryant <russ...@ovn.org> wrote: >> >>> On Fri, Sep 15, 2017 at 12:45 AM, Vikrant Aggarwal >>> <ervikran...@gmail.com> wrote: >>> > Hi Folks, >>> > >>> > With ovs as mechanism driver in neutron, I used network namespaces >>> often to >>> > troubleshoot the network related issue especially with instances which >>> are >>> > not having floating ip attached to them. It's easy to take ssh session >>> to >>> > instances without floating ip from network namespace and then take the >>> > tcpdump at various hops to troubleshoot the issue. >>> > >>> > With ovn, hops are reduced as all decisions are made using openflows >>> but >>> > it's difficult to troubleshoot the issue. >>> > >>> > Do we have any mechanism to take the ssh session to instance with only >>> > private ip in case of ovn and take tcpdump on logical switches and >>> ports? >>> >>> If you're using the latest Neutron integration (networking-ovn), we >>> now create namespaces for OpenStack metadata API integration. You can >>> use those namespaces like you did before. >>> >>> The other option would be to manually create a Neutron port, and then >>> manually create an interface in a namespace for that Neutron port. I >>> can send instructions if needed ... >>> >>> -- >>> Russell Bryant >>> >> >> >> _______________________________________________ >> discuss mailing list >> disc...@openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >> >> > >
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
