[openstack-dev] [neutron][tempest] No metadata route in test_dualnet* family
ihrachys at redhat.com
Thu Feb 11 11:51:43 UTC 2016
Evgeny Antyshev <eantyshev at virtuozzo.com> wrote:
> On 02/11/2016 01:48 PM, Ihar Hrachyshka wrote:
>> 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.
> No, enable_isolated_metadata is False. AFAIU, it forces metadata route
> for isolated subnets,
> but this particular case is the false detection of whether subnet is
> Setting enable_isolated_metadata or force_metadata is a workaround here.
What enable_isolated_metadata does is it makes the static route to point to
DHCP server, not to the subnet gateway (the supposed vRouter IP). The
expected behaviour then is once a previously isolated subnet is attached to
a router, the static route should be changed to point to vRouter. If it’s
not happening, I think it’s a bug.
At the same time, I am not sure DHCP agent should actively stop serving
metadata requests after the subnet is attached to a router: if it does it,
then all instances that already set their networking to use the static
route pointing to DHCP server will loose their metadata access.
>>> 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 routes.
>> 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, enable_isolated_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.
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev