Open Stack

Evgeny Antyshev <eantyshev at virtuozzo.com> wrote:

> Hello!
> 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  
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  
> create_networks()

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.

Ihar