On Monday, 13 January 2014, 13:34, Jonathan Proulx <j...@jonproulx.com> wrote:
On Mon, Jan 13, 2014 at 8:05 AM, Darragh O'Reilly ><dara2002-openst...@yahoo.com> wrote: >> Hi Jon, >> >> the RST is probably because the curl request was to port 8775. Can you try >> again to port 80 and also use -n with tcpdump. > >Thanks for the extra eyes on that one, been a long weekend and not so >much in the good way, I didn't mean to be using :8775 > >> I was able to get metadata from the DHCP namespace proxy on a provider >> network with an external router working by pushing out a static route to >> 169.154.169.254 with DHCP. There are more details and a workarounds here >> https://bugs.launchpad.net/neutron/+bug/1236783 - Note I did not use >> enable_metadata_network. > >That's basicaly what I had working with Grizzly. > >Now I'm getting an internal server error because: > >connect(13, {sa_family=AF_FILE, >path="/var/lib/quantum/metadata_proxy"}, 33) = -1 ECONNREFUSED >(Connection refused) hmm - I wonder if your problem is to do with a quantum/neutron naming mixup? Was this an upgrade install? Your state_path still seems to be /var/lib/quantum/ Is the neutron-metadata-agent listening on /var/lib/neutron/metadata_proxy instead? lsof | grep metadata_proxy > >So I'm thinking I need to extract some leftover Grizzly-quantum stuff. > > >Thanks, >-Jon > > _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
