Open Stack

Thanks for your response, Mark. Can you confirm that the 'q-meta'
service works in Devstack if Devstack was installed about a week or two
ago (we do have the 'RECLONE=yes' option set in localrc) or must we pull
latest from git again?

Best,
Will

-----Original Message-----
From: Mark McClain [mailto:mark.mcclain at dreamhost.com] 
Sent: Thursday, January 03, 2013 12:55 PM
To: Will Dennis
Cc: openstack at lists.launchpad.net
Subject: Re: [Openstack] VMs not able to contact metadata service

Will-

The metadata service in Folsom will only work when overlapping IP ranges
are disabled (see:
http://docs.openstack.org/trunk/openstack-network/admin/content/ch_limit
ations.html).  For Grizzly, we have added metadata service for
overlapping networks.  This feature is currently available in devstack
when you enable the q-meta service.

mark
 
On Jan 2, 2013, at 11:10 PM, Willard Dennis <wdennis at nec-labs.com>
wrote:

> Hello all,
> 
> I am running Folsom with Quantum v2, via Devstack. Am trying to use
Ubuntu UEC image to spawn VMs, but when the VM instance boots, it is not
able to contact the metadata server in order to (among other things)
inject the public key needed in order for me to be able to SSH into the
instance. See http://paste.openstack.org/show/28764/ for a log snippet
if needed.
> 
> Following the (incorrect, bug reported) instructions found at
http://docs.openstack.org/folsom/openstack-compute/admin/content/configu
ring-openstack-compute-basics.html#enabling-access-to-vms-on-the-compute
-node (search for "If you want to use the 10.04 Ubuntu Enterprise Cloud
images" to get to the instructions, and change the metadata port from
the incorrect '8773' to the correct '8775') I added the rule into
iptables, with no luck... I still cannot reach the metadata server at
169.254.169.254:80. When I dump the iptables rules for the 'nat' table,
I see that my added rule is being hit, but it's still not working:
> 
> $ sudo iptables -t nat -L -v -n
> Chain PREROUTING (policy ACCEPT 982 packets, 159K bytes)
> pkts bytes target     prot opt in     out     source
destination         
>  210 27054 nova-compute-PREROUTING  all  --  *      *       0.0.0.0/0
0.0.0.0/0           
>   17  1020 DNAT     tcp  --  *      *       0.0.0.0/0
169.254.169.254      tcp dpt:80 to:xxx.xx.xx.xx:8775   <<<<< (target IP
addr redacted)
> 3078  520K nova-api-PREROUTING  all  --  *      *       0.0.0.0/0
0.0.0.0/0
> 
> I searched and found this thread from this list: 
> http://www.mail-archive.com/openstack@lists.launchpad.net/msg16569.htm
> l Does this mean that the Nova metadata service cannot be used with 
> Quantum when using multiple tenant networks (L3 arch)? (this is the 
> model that Devstack implements in my setup) If the above is true, can 
> I revert to another supported configuration (and kindly give me a 
> pointer as to how?) Finally, any plans to fix the metadata service so 
> that it will work with Quantum's L3 service, and enable this out of 
> the box with Devstack? (dare to dream :)
> 
> Thanks and regards,
> Will
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp