[SRU] Metadata service for instances is unavailable when the l3-agent on the compute host is dvr_snat mode
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu Cloud Archive |
Fix Released
|
Undecided
|
Unassigned | ||
Queens |
Fix Released
|
High
|
Unassigned | ||
Rocky |
Fix Released
|
High
|
Unassigned | ||
Stein |
Fix Released
|
Undecided
|
Unassigned | ||
neutron |
Fix Released
|
Medium
|
Slawek Kaplonski | ||
neutron (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Bionic |
Fix Released
|
High
|
Unassigned | ||
Cosmic |
Fix Released
|
High
|
Unassigned | ||
Disco |
Fix Released
|
High
|
Unassigned | ||
Eoan |
Fix Released
|
High
|
Unassigned |
Bug Description
[Impact]
Currently if you deploy Openstack with dvr and l3ha enabled (and > 1 compute host) only instances that are booted on the compute host that is running the VR master will have access to metadata. This patch ensures that both master and slave VRs have an associated haproxy ns-metadata proccess running local to the compute host.
[Test Case]
* deploy Openstack with dvr and l3ha enabled with 2 compute hosts
* create an ubuntu instance on each compute hosts
* check that both are able to access the metadata api (i.e. cloud-init completes successfully)
* verify that there is an ns-metadata haproxy process running on each compute host
[Regression Potential]
None anticipated
=======
In my mitaka environment, there are five nodes here, including controller, network1, network2, computer1, computer2 node. I start l3-agents with dvr_snat mode in all network and compute nodes and set enable_
* Pre-conditions: start l3-agent with dvr_snat mode in all computer and network nodes and set enable_
* Step-by-step reproduction steps:
1.create a network and a subnet under this network;
2.create a router;
3.add the subnet to the router
4.create an instance with cirros (or other images) on this subnet
5.open the console for this instance and run command 'curl http://
* Expected output: this command should return the true metadata info with the command 'curl http://
* Actual output: the command actually returns "curl: couldn't connect to host"
* Version:
** Mitaka
** All hosts are centos7
tags: | added: l3-dvr-backlog |
tags: | added: l3-bgp |
description: | updated |
description: | updated |
Changed in neutron: | |
assignee: | nobody → Zhixin Li (lizhixin) |
description: | updated |
tags: |
added: l3-ha removed: l3-bgp |
Changed in neutron: | |
importance: | Undecided → High |
Changed in neutron: | |
assignee: | Zhixin Li (lizhixin) → Dongcan Ye (hellochosen) |
status: | New → In Progress |
Changed in neutron: | |
assignee: | Dongcan Ye (hellochosen) → Brian Haley (brian-haley) |
Changed in neutron: | |
assignee: | Brian Haley (brian-haley) → Zhixin Li (lizhixin) |
Changed in neutron: | |
assignee: | Zhixin Li (lizhixin) → nobody |
Changed in neutron: | |
importance: | High → Medium |
Changed in neutron: | |
status: | In Progress → Confirmed |
status: | Confirmed → Won't Fix |
Changed in neutron: | |
assignee: | nobody → Slawek Kaplonski (slaweq) |
status: | Won't Fix → In Progress |
description: | updated |
tags: | added: sts-sru-needed |
summary: |
- Metadata service for instances is unavailable when the l3-agent on the - compute host is dvr_snat mode + [SRU] Metadata service for instances is unavailable when the l3-agent on + the compute host is dvr_snat mode |
Changed in neutron (Ubuntu Eoan): | |
importance: | Undecided → High |
status: | New → Fix Released |
Changed in neutron (Ubuntu Disco): | |
importance: | Undecided → High |
status: | New → Fix Released |
Changed in neutron (Ubuntu Cosmic): | |
importance: | Undecided → High |
status: | New → Triaged |
Changed in neutron (Ubuntu Bionic): | |
importance: | Undecided → High |
status: | New → Triaged |
I found that if a dvr_snat-mode l3-agent isn't a master for a certain router, the l3-agent will destroy the metadata-proxy process in the router' namespace. Therefore, when a l3-agent on a compute node is started with dvr_snat mode, the instances on this compute node can't access the metadata proxy service and fails to run command 'curl http:// 169.254. 169.254'. So If dvr_snat-mode l3-agents on all compute nodes don't destroy metadata-proxy processes in the standby router namespace, the instances on compute nodes can fetch metadata.