[openstack-dev] [neutron][tempest] No metadata route in test_dualnet* family
ihrachys at redhat.com
Thu Feb 11 10:48:13 UTC 2016
Evgeny Antyshev <eantyshev at virtuozzo.com> wrote:
> I need an advice from someone familiar with how Neutron configures
> Metadata routes for created subnets.
Below, I presume you enabled isolated metadata in DHCP agent.
> We run tempest in such an environment that all ssh keys, personality
> files, etc. go through metadata service.
> Which requires metadata route to 169.254.169.254 being provided by DHCP.
> We faced rather complicated problem in scenario/test_network_v6.py:
> Networking configuration comprises of 4 steps:
> 1) Private network creation
> 2) Router creation and plugging it as a gateway in external network
> 3) Subnet creation
> 4) Adding router interface to the subnet
> This sequence leads to that DHCP service provides static metadata route,
> and our scenario works.
> That's how it is done in create_networks() from
> tempest/scenario/manager.py (which used in the majority of tests).
It indeed works, though it seems that the metadata service is served by
DHCP agent, not L3 agent. which is wrong for non-isolated networks. I think
once you attach a network to a router, its metadata service should always
be served by L3 agent.
Once I kill the dnsmasq process and restart the DHCP agent, it’s
reconfigured properly and point to the router. It seems we indeed need to
notify the DHCP agent on router interface plugged to reconfigure metadata
In the code, I don’t see any RPC notifications triggered in
add_router_interface that could be used by the DHCP agent to reconfigure
itself for the new non-isolated world.
Could you please report a bug for that?
> But, prepare_network() of scenario/test_network_v6.py first creates
> subnet, and after that it creates router (1-3-2-4).
> DHCP service configuration in neutron regards this subnet isolated then
> (which is what I don't understand), therefore,
> doesn't provide it with metadata route by default (force_metadata=False,
> I have 2 guesses:
> 1) The neutron behavior is valid, and the sequence of subnet/router
> creation should be changed in prepare_network(), to coincide with
The end result should not differ depending on the order of operations. If
there is a difference, there is definitely a neutron bug.
> 2) Neutron has bug handling such scenario: it doesn't update DHCP service
> configuration when router is created for subnet.
Seems like it.
More information about the OpenStack-dev