Public bug reported:
In a configuration using the dhcp_agent.ini setting
enable_isolated_metadata = True
When creating a network configuration that is *not* isolated it has been
observed that the dnsmasq processes are being configured with static
routes for the metadata-service (169.254.169.254) that point to the
local dhcp server.
ci-info:
+-------+-----------------+------------+-----------------+-----------+-------+
ci-info: | Route | Destination | Gateway | Genmask | Interface |
Flags |
ci-info:
+-------+-----------------+------------+-----------------+-----------+-------+
ci-info: | 0 | 0.0.0.0 | 71.0.0.161 | 0.0.0.0 | eth0 |
UG |
ci-info: | 1 | 71.0.0.160 | 0.0.0.0 | 255.255.255.240 | eth0 |
U |
ci-info: | 2 | 169.254.169.254 | 71.0.0.163 | 255.255.255.255 | eth0 |
UGH |
However, in this particular scenario the dnsmasq processes have no
metadata-proxy processes.
When a VM boots it gets the static route via DHCP and is unable to
access the metadata service.
This issue seems to have appeared due to patch #116832 "Don't spawn
metadata-proxy for non-isolated nets".
Is it possible that the basis for that optimisation is flawed?
The optimisation implements checks of whether a subnet is considered isolated.
These checks include whether a subnet has a neutron router port available.
However, it appears that decision can change during network construction or
manipulation.
That potential change of decision would appear to defeat the previous
optimisation.
Once it has been decided that a network is isolated the static route for
metadata-service may be passed to VMs. At which point we cannot run without
metadata-proxies on the dhcp-servers, even if a neutron router becomes
available and the network become non-isolated.
A proposal would be to remove the optimisation of not launching
metadata-proxy-agents on dhcp-servers. Which means we will return to carrying
the metadata-proxy-agents processes.
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1450548
Title:
Some VMs get a bad metadata route
Status in OpenStack Neutron (virtual network service):
New
Bug description:
In a configuration using the dhcp_agent.ini setting
enable_isolated_metadata = True
When creating a network configuration that is *not* isolated it has
been observed that the dnsmasq processes are being configured with
static routes for the metadata-service (169.254.169.254) that point to
the local dhcp server.
ci-info:
+-------+-----------------+------------+-----------------+-----------+-------+
ci-info: | Route | Destination | Gateway | Genmask | Interface
| Flags |
ci-info:
+-------+-----------------+------------+-----------------+-----------+-------+
ci-info: | 0 | 0.0.0.0 | 71.0.0.161 | 0.0.0.0 | eth0
| UG |
ci-info: | 1 | 71.0.0.160 | 0.0.0.0 | 255.255.255.240 | eth0
| U |
ci-info: | 2 | 169.254.169.254 | 71.0.0.163 | 255.255.255.255 | eth0
| UGH |
However, in this particular scenario the dnsmasq processes have no
metadata-proxy processes.
When a VM boots it gets the static route via DHCP and is unable to
access the metadata service.
This issue seems to have appeared due to patch #116832 "Don't spawn
metadata-proxy for non-isolated nets".
Is it possible that the basis for that optimisation is flawed?
The optimisation implements checks of whether a subnet is considered
isolated. These checks include whether a subnet has a neutron router port
available. However, it appears that decision can change during network
construction or manipulation.
That potential change of decision would appear to defeat the previous
optimisation.
Once it has been decided that a network is isolated the static route for
metadata-service may be passed to VMs. At which point we cannot run without
metadata-proxies on the dhcp-servers, even if a neutron router becomes
available and the network become non-isolated.
A proposal would be to remove the optimisation of not launching
metadata-proxy-agents on dhcp-servers. Which means we will return to carrying
the metadata-proxy-agents processes.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1450548/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
