Open Stack

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.
>
>>
>> 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