On Jun 20, 2012, at 5:44 PM, Lars Kellogg-Stedman wrote:
>>> Is the DNAT rule expected to work? Does linux_net.py need a special
>>> case for when the metadata address is on the local host?
>
> I have confirmed that the DNAT rule works *unless* metadata_host is
> 127.0.0.1, in which case you nee
Generally the suggestion is to not set metadata_host to 127.0.0.1, but to set
it to the actual IP of the compute host. Your code change seems reasonable
however and I don't see any problem merging it if you propose it thorugh gerrit.
Vish
On Jun 20, 2012, at 2:44 PM, Lars Kellogg-Stedman wrote
> > Is the DNAT rule expected to work? Does linux_net.py need a special
> > case for when the metadata address is on the local host?
I have confirmed that the DNAT rule works *unless* metadata_host is
127.0.0.1, in which case you need a REDIRECT rule.
--
Lars Kellogg-Stedman|
Senior Tec
> Is the DNAT rule expected to work? Does linux_net.py need a special
> case for when the metadata address is on the local host?
For now, I've modified linux_net.py so that it conditionally creates a REDIRECT
rule if FLAGS.metadata_host is 127.0.0.1:
def metadata_forward():
"""Create for
> or better yet, just the
> nova-api-metadata service alongside every nova-network.
Right, that's what we've got. The issue right now appears to be that
of a DNAT rule failing where a REDIRECT rule succeeds, and I'm not
sure what's causing that behavior.
Presumably other people have this working
When using the multi-host network mode, the simplest solution is to install
either the whole nova-api service, or better yet, just the
nova-api-metadata service alongside every nova-network.
If you're on Ubuntu, just install the nova-api-metadata package..
Thanks,
Kiall
Sent from my phone.
On Ju
> We are having problems with connectivity from the instance to our
> OpenStack controller (particularly the metadata service)...
zynzel on #openstack suggested that the metadata api service is
supposed to run alongside the compute service, so I've modified our
configuration accordingly to start n
We seem to have OpenStack working correctly with a FlatDHCP network
environment, running in multi_host mode. Outbound connectivity works just fine:
instance# curl http://google.com
301 Moved
301 Moved
The document has moved
http://www.google.com/";>here.
We are having problems wi
8 matches
Mail list logo
