Bug 1662156

Summary:	ovn_metadata_agent tap device didn't mapped integration bridge (br-int) in the compute
Product:	Red Hat OpenStack	Reporter:	Pradipta Kumar Sahoo <psahoo>
Component:	documentation	Assignee:	James Smith <jamsmith>
Status:	CLOSED EOL	QA Contact:	RHOS Documentation Team <rhos-docs>
Severity:	high	Docs Contact:
Priority:	medium
Version:	14.0 (Rocky)	CC:	apevec, dalvarez, dcadzow, jamsmith, jlibosva, lhh, lmartins, majopela, mburns, njohnston, nlevinki
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:	docs-accepted
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-07-06 11:25:09 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Pradipta Kumar Sahoo 2018-12-26 14:00:41 UTC

Description of problem:
In OVN-DVR-HA setup, the metadata service has served in compute where the OVN has created ovnmeta namespace where the tap port has configured with internal subnet IP. But the tap-port doesn't map to br-int in the compute node. In OVS-ML2 scenario for any qdhcp namespace, the tap-port of the namespace has created in br-int.

Due to insufficient information available in our official document, this is not clear us that how the ovn-meta namespace serving the metadata service to the cloud instance.
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html-single/networking_with_open_virtual_network/#deploying_the_ovn_metadata_agent_on_compute_nodes

Version-Release number of selected component (if applicable):
Red Hat OpenStack 13
Red Hat OpenStack 14

Steps to Reproduce:
1. Port details of OVN-Metadata
@compute-0 ~]# ip netns exec ovnmeta-548adde8-fae5-47c3-b580-9ae6d2c6a608 ip r
169.254.0.0/16 dev tap548adde8-f1 proto kernel scope link src 169.254.169.254 
192.168.1.0/24 dev tap548adde8-f1 proto kernel scope link src 192.168.1.2 


2. The configured OVN-Metadata port (tap548adde8-f1) doesn't mapp to integration bridge (br-int).
@compute-0 ~]# ovs-ofctl -O OpenFlow13 dump-ports-desc br-int
OFPST_PORT_DESC reply (OF1.3) (xid=0x2):
 1(ovn-cf7866-0): addr:c6:05:e9:07:cd:7b
     config:     0
     state:      LIVE
     speed: 0 Mbps now, 0 Mbps max
 2(ovn-ec0da3-0): addr:b2:3b:84:49:c8:e5
     config:     0
     state:      LIVE
     speed: 0 Mbps now, 0 Mbps max
 3(ovn-1097e4-0): addr:16:4a:20:b4:05:00
     config:     0
     state:      LIVE
     speed: 0 Mbps now, 0 Mbps max
 4(ovn-ae3d3b-0): addr:82:bd:26:92:69:36
     config:     0
     state:      LIVE
     speed: 0 Mbps now, 0 Mbps max
 5(tap5c197987-bf): addr:fe:16:3e:3d:20:70
     config:     0
     state:      LIVE
     current:    10MB-FD COPPER
     speed: 10 Mbps now, 0 Mbps max
 6(patch-br-int-to): addr:4a:f5:85:31:7d:89
     config:     0
     state:      LIVE
     speed: 0 Mbps now, 0 Mbps max
 7(tap548adde8-f0): addr:c2:47:24:63:1e:88
     config:     0
     state:      LIVE
     current:    10GB-FD COPPER
     speed: 10000 Mbps now, 0 Mbps max
 LOCAL(br-int): addr:3e:bc:84:71:3b:47
     config:     PORT_DOWN
     state:      LINK_DOWN
     speed: 0 Mbps now, 0 Mbps max

Expected results:
Can we ellaborate the following section with OVN metadata agent flow which helps for validation and troubleshooting purpose.
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html-single/networking_with_open_virtual_network/#deploying_the_ovn_metadata_agent_on_compute_nodes

Comment 2 Daniel Alvarez Sanchez 2019-01-08 22:58:37 UTC

Hi, you can find how Metadata service is implemented here [0] using networking-ovn.
The metadata agent will create a veth pair; one end is placed inside the ovnmeta namespace and the other is plugged into br-int.

Quoting from the doc upstream:

Creating a VETH pair (OVS upgrades that upgrade the kernel module will make internal ports go away and then brought back by OVS scripts. This may cause some disruption. Therefore, veth pairs are preferred over internal ports).

From your paste in the bug description, you can see that only difference is the last character of the name: '1' for the OVS end and '0' for the namespace one:

tap548adde8-f1
tap548adde8-f0

If you feel that we should clarify our docs, let's handle it as a documentation bug. What do you think?
For now I'll reassign this to DFG:Docs but feel free to proceed as needed.


[0] https://docs.openstack.org/networking-ovn/latest/contributor/design/metadata_api.html