Some VMs get a bad metadata route
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Expired
|
Medium
|
Unassigned |
Bug Description
In a configuration using the dhcp_agent.ini setting
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-
Changed in neutron: | |
importance: | Undecided → Medium |
status: | New → Confirmed |
Changed in neutron: | |
assignee: | nobody → Cedric Brandily (cbrandily) |
This has been observed in a Juno environment.
It has not yet been verified in Kilo