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
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-0008dbbe04 a1, fixed ip address: 10.1.0.5, port id: 1cb39de5- 6f27-4dc9- ab0d-8709b682eb d7 bound in host: ubuntu- bionic- rax-dfw- 0001460688 Compute1, router id 50456504- e7e2-45c4- 8b9d-2c8a7ee93c 4e) gets metadata service correctly through the metadata proxy: http:// paste.openstack .org/show/ 740465/
2) The other instance (instance id 35814d32- 0769-4904- 8332-638eb729e1 1f, fixed ip address: 10.1.0.13, port id: a685e1a1- 0d79-4c54- 8cea-5bf7883fcb 93, bound in host ubuntu- bionic- rax-dfw- 0001460687 controller, router id 50456504- e7e2-45c4- 8b9d-2c8a7ee93c 4e) 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-2c8a7ee93c 4e. 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-2a03510bb1 d3, that is created by test_connectivi ty_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