On 02/11/2016 01:48 PM, Ihar Hrachyshka wrote:
Evgeny Antyshev <[email protected]> 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:
[email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
