Hello, I would suggest to open a bug on launchpad to track this issue.
thank you Saverio 2018-06-18 12:19 GMT+02:00 Radu Popescu | eMAG, Technology <radu.pope...@emag.ro>: > Hi, > > We're using Openstack Ocata, deployed using Openstack Ansible v15.1.7. > Neutron server is v10.0.3. > I can see enable_isolated_metadata and enable_metadata_network only used for > isolated networks that don't have a router which is not our case. > Also, I checked all namespaces on all our novas and only affected 6 out of > 66 ..and only 1 namespace / nova. Seems like isolated case that doesn't > happen very often. > > Can it be RabbitMQ? I'm not sure where to check. > > Thanks, > Radu > > On Fri, 2018-06-15 at 17:11 +0200, Saverio Proto wrote: > > Hello Radu, > > > yours look more or less like a bug report. This you check existing > > open bugs for neutron ? Also what version of openstack are you running > > ? > > > how did you configure enable_isolated_metadata and > > enable_metadata_network options ? > > > Saverio > > > 2018-06-13 12:45 GMT+02:00 Radu Popescu | eMAG, Technology > > <radu.pope...@emag.ro>: > > Hi all, > > > So, I'm having the following issue. I'm creating a VM with floating IP. > > Everything is fine, namespace is there, postrouting and prerouting from the > > internal IP to the floating IP are there. The only rules missing are the > > rules to access metadata service: > > > -A neutron-l3-agent-PREROUTING -d 169.254.169.254/32 -i qr-+ -p tcp -m tcp > > --dport 80 -j REDIRECT --to-ports 9697 > > -A neutron-l3-agent-PREROUTING -d 169.254.169.254/32 -i qr-+ -p tcp -m tcp > > --dport 80 -j MARK --set-xmark 0x1/0xffff > > > (this is taken from another working namespace with iptables-save) > > > Forgot to mention, VM is booting ok, I have both the default route and the > > one for the metadata service (cloud-init is running at boot time): > > [ 57.150766] cloud-init[892]: ci-info: > > +--------+------+--------------+---------------+-------+-------------------+ > > [ 57.150997] cloud-init[892]: ci-info: | Device | Up | Address | > > Mask | Scope | Hw-Address | > > [ 57.151219] cloud-init[892]: ci-info: > > +--------+------+--------------+---------------+-------+-------------------+ > > [ 57.151431] cloud-init[892]: ci-info: | lo: | True | 127.0.0.1 | > > 255.0.0.0 | . | . | > > [ 57.151627] cloud-init[892]: ci-info: | eth0: | True | 10.240.9.186 | > > 255.255.252.0 | . | fa:16:3e:43:d1:c2 | > > [ 57.151815] cloud-init[892]: ci-info: > > +--------+------+--------------+---------------+-------+-------------------+ > > [ 57.152018] cloud-init[892]: ci-info: > > +++++++++++++++++++++++++++++++Route IPv4 > > info++++++++++++++++++++++++++++++++ > > [ 57.152225] cloud-init[892]: ci-info: > > +-------+-----------------+------------+-----------------+-----------+-------+ > > [ 57.152426] cloud-init[892]: ci-info: | Route | Destination | > > Gateway | Genmask | Interface | Flags | > > [ 57.152621] cloud-init[892]: ci-info: > > +-------+-----------------+------------+-----------------+-----------+-------+ > > [ 57.152813] cloud-init[892]: ci-info: | 0 | 0.0.0.0 | > > 10.240.8.1 | 0.0.0.0 | eth0 | UG | > > [ 57.153013] cloud-init[892]: ci-info: | 1 | 10.240.1.0 | > > 0.0.0.0 | 255.255.255.0 | eth0 | U | > > [ 57.153202] cloud-init[892]: ci-info: | 2 | 10.240.8.0 | > > 0.0.0.0 | 255.255.252.0 | eth0 | U | > > [ 57.153397] cloud-init[892]: ci-info: | 3 | 169.254.169.254 | > > 10.240.8.1 | 255.255.255.255 | eth0 | UGH | > > [ 57.153579] cloud-init[892]: ci-info: > > +-------+-----------------+------------+-----------------+-----------+-------+ > > > The extra route is there because the tenant has 2 subnets. > > > Before adding those 2 rules manually, I had this coming from cloud-init: > > > [ 192.451801] cloud-init[892]: 2018-06-13 12:29:26,179 - > > url_helper.py[WARNING]: Calling > > 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [0/120s]: > > request error [('Connection aborted.', error(113, 'No route to host'))] > > [ 193.456805] cloud-init[892]: 2018-06-13 12:29:27,184 - > > url_helper.py[WARNING]: Calling > > 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [1/120s]: > > request error [('Connection aborted.', error(113, 'No route to host'))] > > [ 194.461592] cloud-init[892]: 2018-06-13 12:29:28,189 - > > url_helper.py[WARNING]: Calling > > 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [2/120s]: > > request error [('Connection aborted.', error(113, 'No route to host'))] > > [ 195.466441] cloud-init[892]: 2018-06-13 12:29:29,194 - > > url_helper.py[WARNING]: Calling > > 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [3/120s]: > > request error [('Connection aborted.', error(113, 'No route to host'))] > > > I can see no errors in neither nova or neutron services. > > In the mean time, I've searched all our nova servers for this kind of > > behavior and we have 1 random namespace missing those rules on 6 of our 66 > > novas. > > > Any ideas would be greatly appreciated. > > > Thanks, > > Radu > > > _______________________________________________ > > OpenStack-operators mailing list > > OpenStack-operators@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
