[Bug 2074504] Re: [SRU] Manila's NeutronNetworkPlugin with external networks doesn't work with OVN

[Rodrigo Barbieri]

** Also affects: manila (Ubuntu)
   Importance: Undecided
       Status: New

** Also affects: manila (Ubuntu Jammy)
   Importance: Undecided
       Status: New

** Also affects: manila (Ubuntu Noble)
   Importance: Undecided
       Status: New

** Also affects: manila (Ubuntu Oracular)
   Importance: Undecided
       Status: New

** Changed in: manila (Ubuntu Oracular)
       Status: New => Fix Released

** Changed in: manila (Ubuntu Jammy)
       Status: New => In Progress

** Changed in: manila (Ubuntu)
       Status: New => Fix Released

** Changed in: manila (Ubuntu Noble)
       Status: New => In Progress

** Also affects: cloud-archive
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/bobcat
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/yoga
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/zed
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/antelope
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/epoxy
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/dalmatian
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/caracal
   Importance: Undecided
       Status: New

** Changed in: cloud-archive/epoxy
       Status: New => Fix Released

** Changed in: cloud-archive/dalmatian
       Status: New => Fix Released

** Changed in: cloud-archive/zed
       Status: New => Won't Fix

** Changed in: cloud-archive/bobcat
       Status: New => Won't Fix

** Changed in: cloud-archive/antelope
       Status: New => Won't Fix

** Changed in: cloud-archive/caracal
       Status: New => In Progress

** Changed in: cloud-archive/yoga
       Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to manila in Ubuntu.
https://bugs.launchpad.net/bugs/2074504

Title:
  [SRU] Manila's NeutronNetworkPlugin with external networks doesn't
  work with OVN

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive antelope series:
  Won't Fix
Status in Ubuntu Cloud Archive bobcat series:
  Won't Fix
Status in Ubuntu Cloud Archive caracal series:
  In Progress
Status in Ubuntu Cloud Archive dalmatian series:
  Fix Released
Status in Ubuntu Cloud Archive epoxy series:
  Fix Released
Status in Ubuntu Cloud Archive yoga series:
  In Progress
Status in Ubuntu Cloud Archive zed series:
  Won't Fix
Status in OpenStack Shared File Systems Service (Manila):
  Fix Released
Status in manila package in Ubuntu:
  Fix Released
Status in manila source package in Jammy:
  In Progress
Status in manila source package in Noble:
  In Progress
Status in manila source package in Oracular:
  Fix Released

Bug description:
  *********** SRU TEMPLATE AT THE BOTTOM ***********

  Description
  ===========

  When using NeutronNetworkPlugin with DHSS=True, manila requests
  neutron ports for creating network connections on share servers on the
  user provided Share Network.

  Deployers and users have the flexibility to use external networks
  (i.e., a "provider networks" in neutron parlance) as their Share
  Networks. When they do this, they expect to use Neutron to merely
  perform IPAM. Neutron does create ports to reserve IP addresses;
  however, we don't expect these ports to work or respond to ARP
  requests. This worked even when OVN was used as the ML2 plugin in the
  deployment; however, OVN had a change in its default behavior [1].
  This change makes OVN setup flows for DOWN ports; when ARP responses
  are received from OVN ports, traffic is effectively misrouted/dropped.
  This means that end users cannot reach their share export paths from
  their eventual VMs/containers/bare metal hosts. OVN has a
  configuration option to turn this behavior off ("ignore_lsp_down"). By
  default, OpenStack Neutron sets this "ignore_lsp_down" option to False
  [2] - meaning OVN is not supposed to setup flow table entries for any
  ports that are DOWN.

  However, this behavior isn't working as one would expect.

  Steps to reproduce
  ==================

  A chronological list of steps which will help reproduce the issue you hit:
  * Create a provider network on OpenStack
  * Configure manila with a DHSS=True driver that can use an "external" storage system (example, NetApp)
  * Create a share network mapped to the provider network
  * Create a share with the share network
  * Create a tenant VM
  * Create appropriate access rule/s in manila
  * Attempt to mount the share in the VM

  Expected result
  ===============
  Share is reachable/mountable

  Actual result
  =============
  Share failed to be mounted. Cannot ping the export IPs either because the provider network is unreachable. When you debug this further, you'll notice packets are dropped, citing a MAC address mismatch.

  Environment
  ===========
  1. Version of OpenStack Manila: OpenStack Wallaby

  2. Which storage backend did you use: NetApp (although this should be
  a problem with any non-generic DHSS=true backend)

  3. Which networking type did you use? OVN

  [1] https://www.mail-archive.com/ovs-dev@openvswitch.org/msg60064.html
  [2] https://review.opendev.org/c/openstack/neutron/+/896545

  ===============
  SRU DESCRIPTION
  ===============

  [Impact]

  This issue blocks connectivity of users to external storage backends
  when using OVN, therefore the users cannot access their shares.

  [Test case]

  We cannot reproduce the issue in Canonical lab as we don't have any
  external storage with DHSS=True mode. I tried to reproduce it with the
  generic driver in DHSS=True mode but couldn't. The included unit tests
  should provide coverage. Additionally we have already provided test
  PPAs to customers affected with the issue and they confirmed the issue
  was addressed. Some upstream users have also validated the fix.

  [Where problems could occur]

  The code only affects the neutron plugin for manila, which is used
  only for DHSS=True mode. However, the code is shared between both OVN
  and OVS modes, so attempting to fix the issue for OVN could
  potentially break all the current users using OVS. On the other hand,
  OVN users are broken without connectivity so the benefits generally
  outweight the risks here. If any issues arise, the package will have
  to be downgraded to restore the previous state for OVS users.

  [Other Info]

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/2074504/+subscriptions