Bug 1662156 - ovn_metadata_agent tap device didn't mapped integration bridge (br-int) in the compute
Summary: ovn_metadata_agent tap device didn't mapped integration bridge (br-int) in th...
Keywords:
Status: NEW
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation
Version: 14.0 (Rocky)
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: RHOS Documentation Team
QA Contact: RHOS Documentation Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-26 14:00 UTC by Pradipta Kumar Sahoo
Modified: 2020-01-21 05:01 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.