Posting is addressing question been asked at ask.openstack.org ([1])
Question :-
Can meta-data co-exist in qrouter and qdhcp namespace at the same time
Answer is as follows :-
All private networks (having neutron router) created before or after this change will continue provide metadata via neutron-ns-metadata-proxy running in corresponding qrouter-namespace for theirs VMs.
Any isolated tenants network been created after update will provide metadata via neutron-ns-metadata-proxy running in corresponding qdhcp-namespace for theirs VMs. See http://techbackground.blogspot.com/2013/06/metadata-via-dhcp-namespace.html
******************************************************************
For routable qdhcp-namespace created before update dhcp_agent.ini
******************************************************************
[root@vfedora22wks ~(keystone_admin)]# ip netns exec \
qdhcp-e86eebdb-71bd-4929-937c-2ab57db30e18 netstat -4 -anpt
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address
State PID/Program name
tcp 0 0 50.0.0.10:53 0.0.0.0:*
LISTEN 6773/dnsmasq
tcp 0 0 169.254.169.254:53 0.0.0.0:*
LISTEN 6773/dnsmasq
tcp 0 0 50.0.0.10:42011 50.0.0.15:22
ESTABLISHED 2784/ssh
So it still gets access to metadata via qrouter's ns-metadata-proxy
******************************************************************************
For isolated qdhcp-namespaces /bin/neutron-ns-metadata-proxy
gets started in corresponding qdhcp-namespace
******************************************************************************
[root@vfedora22wks ~(keystone_admin)]# ip netns exec \
qdhcp-e0f08063-2002-4cc9-b7b1-611925ad01e5 netstat -4 -anpt
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
6333/python2
tcp 0 0 30.0.0.10:53 0.0.0.0:* LISTEN
6771/dnsmasq
tcp 0 0 169.254.169.254:53 0.0.0.0:* LISTEN
6771/dnsmasq
[root@vfedora22wks ~(keystone_admin)]# ps -f --pid 6333 | fold -s -w 82
UID PID PPID C STIME TTY TIME CMD
neutron 6333 1 0 20:38 ? 00:00:00 /usr/bin/python2
/bin/neutron-ns-metadata-proxy
--pid_file=/var/lib/neutron/external/pids/e0f08063-2002-4cc9-b7b1-611925ad01e5.pid
--metadata_proxy_socket=/var/lib/neutron/metadata_proxy <====
--network_id=e0f08063-2002-4cc9-b7b1-611925ad01e5 --state_path=/var/lib/neutron
--metadata_port=80 --metadata_proxy_user=983 --metadata_proxy_group=977 --verbose
--log-file=neutron-ns-metadata-proxy-e0f08063-2002-4cc9-b7b1-611925ad01e5.log
--log-dir=/var/log/neutron
For private_network having neutron router and created immediately after update
"enable_isolated_metadata=True" and service restart
[root@vfedora22wks ~(keystone_admin)]
# ip netns exec \
qdhcp-6e4646d8-2c5f-4adc-a4dc-51884f090d09 netstat -4 -anpt
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:*
LISTEN 8654/python2
tcp 0 0 60.0.0.10:53 0.0.0.0:*
LISTEN 8626/dnsmasq
tcp 0 0 169.254.169.254:53 0.0.0.0:*
LISTEN 8626/dnsmasq
[root@vfedora22wks ~(keystone_admin)]# ps -f --pid 8654 | fold -s -w 82
UID PID PPID C STIME TTY TIME CMD
neutron 8654 1 0 20:43 ? 00:00:00 /usr/bin/python2
/bin/neutron-ns-metadata-proxy
--pid_file=/var/lib/neutron/external/pids/6e4646d8-2c5f-4adc-a4dc-51884f090d09.pid
--metadata_proxy_socket=/var/lib/neutron/metadata_proxy <=====
--network_id=6e4646d8-2c5f-4adc-a4dc-51884f090d09 --state_path=/var/lib/neutron
--metadata_port=80 --metadata_proxy_user=983 --metadata_proxy_group=977 --verbose
--log-file=neutron-ns-metadata-proxy-6e4646d8-2c5f-4adc-a4dc-51884f090d09.log
--log-dir=/var/log/neutron
However,I have noticed that nodes restart disables neutron-ns-metadata-proxy for route-able tenant's networks, e.g. neutron-router port exists on corresponding network. VM's metadata request is routed via qdhcp-namespace to qrouter-namespace
VMs get metadata from neutron-ns-metadata-proxy running in qrouter-namespace.
For isolated qdhcp-namespaces node reboot still keeps neutron-ns-metadata-proxy in corresponding qdhcp-namespace
*******************************************************************************************************
All Nodes rebooted neutron-ns-metadata-proxy is no longer kept in route-able qdhcp-namespaces. VMs are serving via neutron-ns-metadata-proxy running in qrouter-namespace.
*******************************************************************************************************
Launching CirrOS instance via isolated network
Verification neutron-ns-metadata-proxy status
Launching VF22Devs07 VM via route-able tenant's network demo_network
Verification neutron-ns-metadata-proxy status
No comments:
Post a Comment