Comment 8 for bug 1795870

Analyzing the failure of test_trunk_subport_lifecycle in http://logs.openstack.org/90/627990/1/check/neutron-tempest-plugin-dvr-multinode-scenario/c760de2/testr_results.html.gz i find the following:

1) One of the instances (instance id 0580b44c-c56d-4683-b567-0008dbbe04a1, fixed ip address: 10.1.0.5, port id: 1cb39de5-6f27-4dc9-ab0d-8709b682ebd7 bound in host: ubuntu-bionic-rax-dfw-0001460688 Compute1, router id 50456504-e7e2-45c4-8b9d-2c8a7ee93c4e) gets metadata service correctly through the metadata proxy: http://paste.openstack.org/show/740465/

2) The other instance (instance id 35814d32-0769-4904-8332-638eb729e11f, fixed ip address: 10.1.0.13, port id: a685e1a1-0d79-4c54-8cea-5bf7883fcb93, bound in host ubuntu-bionic-rax-dfw-0001460687 controller, router id 50456504-e7e2-45c4-8b9d-2c8a7ee93c4e) cannot get metadata service. Metadata proxy lines for that router cannot be found in the L3 agent log file in the controller. In fact the L3 agent log file in the controller has no lines referencing router 50456504-e7e2-45c4-8b9d-2c8a7ee93c4e. As a consequence, we find failure to contact the metadata service in the instance's console log: http://paste.openstack.org/show/740467/

3) With other routers the metadata proxy works in both nodes. For example router d258390e-a30e-4302-a26a-2a03510bb1d3, that is created by test_connectivity_through_2_routers. These are the ha-proxy logs for that router from the L3 agents log files in both controller and compute1: http://paste.openstack.org/show/740472/ and http://paste.openstack.org/show/740471.

Based on these findings, next step is to investigate how the routers are being scheduled