Bug 2300098

Summary:	Manila IPAM approach for NetAppDriver is not aligned with OVN internals and OVN breaks network communications between VMs and shares
Product:	Red Hat OpenStack	Reporter:	Alex Stupnikov <astupnik>
Component:	openstack-manila	Assignee:	Goutham Pacha Ravi <gouthamr>
Status:	CLOSED ERRATA	QA Contact:	Alfredo <alfrgarc>
Severity:	high	Docs Contact:
Priority:	urgent
Version:	17.1 (Wallaby)	CC:	ashrodri, gouthamr, gregraka, jelynch, joflynn, mariel, mburns, parthee, vhariria
Target Milestone:	z4	Keywords:	Triaged
Target Release:	17.1
Hardware:	Unspecified
OS:	All
Whiteboard:
Fixed In Version:	openstack-manila-12.1.3-17.1.20240829070802.ba479a4.el9ost	Doc Type:	Bug Fix
Doc Text:	Before this update, if you used an external network as a share network for the Shared File Systems service (manila), an incompatibility in OVN caused incorrect ARP responses for ports that were created on external switches attached to external storage systems. Client machines, such as virtual machines, containers, or bare metal nodes, could not reach shares that were exported on external networks. + With this update, the Shared File Systems service sets the OpenStack network port status to DOWN to prevent OVN from setting up ARP responses through Networking service (neutron) ports. Instead, MAC addresses are learned from the external ports. Client machines can reach shares that are exported on external networks, and they can mount the shares when there are access control lists (ACLs) in the Shared File Systems service.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2024-11-21 09:42:01 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 Alex Stupnikov 2024-07-26 17:04:13 UTC

Description of problem:
Goutham from RHOS Storage engineering was already involved in ongoing escalation for one of our customers and knows context. Shortly speaking, MAC address used by NetApp storage to host shares is not static and impossible to predict. As a result, a manila:share port created by Manila has a MAC address that doesn't match real MAC address used by storage.

This situation causes problems inside OVN because it expects different MAC address to be used by VMs when they are communicating with storage. As a result, traffic is dropped. One of workarounds proposed by OVN team is to disable Neutron port.

There is existing issue https://issues.redhat.com/browse/FDP-697 reported for OVN, I am reporting this bug to ask Manila team to check if it is possible to do something on their side and maybe discuss this problem with OVN engineers. For example, disabling the port in Neutron fixes this problem and if port is only created for IPAM purposes, then maybe disabling it will help? Or this is not going to work because we rely on OVN to create some security groups?

Version-Release number of selected component (if applicable):
RHOSP 17.1


Steps to Reproduce:
1. Create a share with NetApp backend
2. Try to ping share from some VM

Actual results: no network connectivity


Expected results: VM is able to reach NetApp storage


Additional info: there is extensive discussion in attached support case

Comment 20 errata-xmlrpc 2024-11-21 09:42:01 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (RHOSP 17.1.4 bug fix and enhancement advisory), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2024:9974