Open Stack

Hi, Sergey,
I remember I had similar problem when I switched to quantum(neutron's 
previous name) from nova-network.
But, I can't recall how I solved it exactly, it would be something like 
previous nova-network NAT caused the problem, so, if you switched to 
neutron from nova-network at the same system, you might want to look at 
your NAT to see if you still have some NAT setup remaining that came 
from nova-network, and (e.g. redirect :80 to 0.0.0.0:8775)
	
 >     I guess, metadata service is supposed to listen on 192.168.0.2, 
but  it's not.
Yes, it's not, if I understand it correctly, it will be redirected to 
metadata port in name space, so, you won't see it actually listens on 80 
port.


Best regards,
Felix Lee ~

On 2014年06月14日 19:44, Sergey Motovilovets wrote:
>
> This can probably be useful too:
>
>  From network node
>
> # ip netns ls
> qdhcp-1b982b98-62db-4c87-867b-0490bac8fb52
> qrouter-c7e7ea00-a362-4f4f-9a1c-a54ac86eb3be
>
> # ps -x | grep metadata
> �1469 ? � � � �S � � �0:00 /usr/bin/python
> /usr/bin/neutron-ns-metadata-proxy
> --pid_file=/var/lib/neutron/external/pids/6c91714c-c1aa-41d7-88ba-249df3a8368c.pid
> --metadata_proxy_socket=/var/lib/neutron/metadata_proxy
> --network_id=6c91714c-c1aa-41d7-88ba-249df3a8368c
> --state_path=/var/lib/neutron --metadata_port=80
> --log-file=neutron-ns-metadata-proxy-6c91714c-c1aa-41d7-88ba-249df3a8368c.log
> --log-dir=/var/log/neutron
> �5937 ? � � � �S � � �0:00 /usr/bin/python
> /usr/bin/neutron-ns-metadata-proxy
> --pid_file=/var/lib/neutron/external/pids/fa72c69b-2ca2-4d4d-ab8c-d6fa6e8e72d6.pid
> --metadata_proxy_socket=/var/lib/neutron/metadata_proxy
> --network_id=fa72c69b-2ca2-4d4d-ab8c-d6fa6e8e72d6
> --state_path=/var/lib/neutron --metadata_port=80
> --log-file=neutron-ns-metadata-proxy-fa72c69b-2ca2-4d4d-ab8c-d6fa6e8e72d6.log
> --log-dir=/var/log/neutron
> �8108 ? � � � �S � � �0:00 /usr/bin/python
> /usr/bin/neutron-ns-metadata-proxy
> --pid_file=/var/lib/neutron/external/pids/c7e7ea00-a362-4f4f-9a1c-a54ac86eb3be.pid
> --metadata_proxy_socket=/var/lib/neutron/metadata_proxy
> --router_id=c7e7ea00-a362-4f4f-9a1c-a54ac86eb3be
> --state_path=/var/lib/neutron --metadata_port=9697
> --log-file=neutron-ns-metadata-proxy-c7e7ea00-a362-4f4f-9a1c-a54ac86eb3be.log
> --log-dir=/var/log/neutron
>
>
>
> 2014-06-14 20:38 GMT+03:00 Sergey Motovilovets
> <motovilovets.sergey at gmail.com <mailto:motovilovets.sergey at gmail.com>>:
>
>     Hi, Mike.
>
>     There are no routes in my VM's except for the default one. Private
>     subnet I'm using is 192.168.0.0/24 <http://192.168.0.0/24> with
>     neutron router on 192.168.0.1.
>
>     # route -n
>     Kernel IP routing table
>     Destination � � Gateway � � � � Genmask � � � � Flags Metric Ref �
>     �Use Iface
>     0.0.0.0 � � � � 192.168.0.1 � � 0.0.0.0 � � � � UG � �0 � � �0 � � �
>     �0 eth0
>     192.168.0.0 � � 0.0.0.0 � � � � 255.255.255.0 � U � � 0 � � �0 � � �
>     �0 eth0
>
>     Following is a part of Fedora cloud-init script output. Instance
>     tries to get info from 169.254.169.254 and then switches to
>     192.168.0.2, which is an interface with dnsmasq injected by neutron.
>     I guess, metadata service is supposed to listen on 192.168.0.2, but
>     it's not.
>
>     [ 61.409140] cloud-init[512]: 2014-06-14 17:23:53,183 -
>     url_helper.py[WARNING]: Calling
>     'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed
>     [50/120s]: request error [HTTPConnectionPool(host='169.254.169.254',
>     port=80): Request timed out. (timeout=50.0)]
>
>     [  112.463197] cloud-init[512]: 2014-06-14 17:24:44,237 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [101/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Request timed out. (timeout=50.0)]
>     [  130.489916] cloud-init[512]: 2014-06-14 17:25:02,264 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [119/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Request timed out. (timeout=17.0)]
>     [  131.494462] cloud-init[512]: 2014-06-14 17:25:03,266 - DataSourceEc2.py[CRITICAL]: Giving up on md from ['http://169.254.169.254/2009-04-04/meta-data/instance-id'] after 120 seconds
>     [  131.502647] cloud-init[512]: 2014-06-14 17:25:03,273 - url_helper.py[WARNING]: Calling 'http://192.168.0.2//latest/meta-data/instance-id' failed [0/120s]: request error [HTTPConnectionPool(host='192.168.0.2', port=80): Max retries exceeded with url: //latest/meta-data/instance-id (Caused by <class 'socket.error'>: [Errno 111] Connection refused)]
>
>
>
>
>
>     2014-06-14 20:04 GMT+03:00 Mike Spreitzer <mspreitz at us.ibm.com
>     <mailto:mspreitz at us.ibm.com>>:
>
>         Sergey Motovilovets <motovilovets.sergey at gmail.com
>         <mailto:motovilovets.sergey at gmail.com>> wrote on 06/14/2014
>         11:00:09 AM:
>         ...
>
>          > Another problem is metadata service. I've tried like
>         everything I
>          > found regarding neutron<->metadata configuration, without any
>          > success. I just can't connect to 169.254.169.254 from virtual
>          > machines, though they get configured by dhcp, can ping each
>         other in
>          > their subnet and I can allocate floating IPs to them.
>
>          > ...
>
>         Did yo look to see if there is a wrong route in your VM?
>         �Sometimes I find the metadata service is messed up by a bogus
>         entry in the VM's routing table.
>
>         Regards,
>         Mike
>
>
>
>
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>


-- 
Felix H.T Lee                           Academia Sinica Grid & Cloud.
Tel: +886-2-27898308
Office: Room P111, Institute of Physics, 128 Academia Road, Section 2, 
Nankang, Taipei 115, Taiwan