Open Stack

Evgeny Antyshev <eantyshev at virtuozzo.com> wrote:

>
>
> On 02/11/2016 01:48 PM, Ihar Hrachyshka wrote:
>> 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.
> 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  
> isolated.
> 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?
> https://bugs.launchpad.net/neutron/+bug/1544515
>>> 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
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev