[Bug 2156566] Re: neutron-ovs-agent crashes on restart with tunneling disabled (tun_br is None)

[Guillaume Boutry]

** Changed in: neutron (Ubuntu Resolute)
       Status: In Progress => Fix Committed

** Changed in: neutron (Ubuntu)
       Status: In Progress => Fix Released

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

Title:
  neutron-ovs-agent crashes on restart with tunneling disabled (tun_br
  is None)

Status in Ubuntu Cloud Archive:
  New
Status in Ubuntu Cloud Archive gazpacho series:
  In Progress
Status in neutron:
  Fix Released
Status in neutron package in Ubuntu:
  Fix Released
Status in neutron source package in Resolute:
  Fix Committed

Bug description:
  [Impact]

  On an ML2/OVS deployment with tunneling disabled
  (enable_tunneling=False, flat/vlan type drivers, no br-tun), neutron-
  openvswitch-agent crashes on every restart:

      ERROR neutron...ovs_oskenapp Agent main thread died of an exception: AttributeError: 'NoneType' object has no attribute 'get_flood_to_tun_ofports'
        File ".../ovs_neutron_agent.py", line 342, in __init__
          self._restore_local_vlan_map()
        File ".../ovs_neutron_agent.py", line 520, in _restore_local_vlan_map
          tun_ofports = self.tun_br.get_flood_to_tun_ofports(local_vlan)
      AttributeError: 'NoneType' object has no attribute 'get_flood_to_tun_ofports'

  _restore_local_vlan_map(), called from OVSNeutronAgent.__init__(), calls self.tun_br.get_flood_to_tun_ofports() for every integration-bridge port carrying other_config:net_uuid, without checking whether tunneling is enabled.
  With tunneling disabled self.tun_br is None, so the call raises.

  The call sits behind "if net_uuid:", and an integration-bridge port
  only carries net_uuid in its OVS other_config after the agent has
  written it during normal operation:

      1st start:  ports have NO net_uuid  ->  skipped  ->  OK
      restart:    ports HAVE   net_uuid   ->  called   ->  crash

  Because the crash happens in __init__, the agent never reaches rpc_loop and never reprograms OVS flows, so instances on the node lose provider-network connectivity until manual recovery.
  Clearing net_uuid by hand recovers the agent once, but the agent rewrites it during operation and the next restart crashes again:

      ovs-vsctl remove Port <integration-bridge-tap-port> other_config net_uuid
      systemctl restart neutron-openvswitch-agent

  [Test Plan]

  Deploy ML2/OVS with tunneling disabled on the target release:

      # /etc/neutron/plugins/ml2/ml2_conf.ini
      [ml2]
      type_drivers = flat,vlan
      tenant_network_types = vlan
      mechanism_drivers = openvswitch

      # /etc/neutron/plugins/ml2/openvswitch_agent.ini
      [ovs]
      bridge_mappings = physnet1:br-data

      [agent]
      tunnel_types =

  enable_tunneling is not a config option: the agent derives it as bool(tunnel_types), so leaving tunnel_types empty is what disables tunneling and leaves self.tun_br as None.
  Confirm no tunnel bridge was created:

      ovs-vsctl list-br

  There must be no br-tun in the output.

  Boot an instance on a flat or VLAN provider network so that the agent
  writes net_uuid into the integration-bridge port, then confirm the
  ports carry it:

      ovs-vsctl --columns=name,other_config list Port | grep net_uuid

  Before the patch (reproduce the crash):

      systemctl restart neutron-openvswitch-agent
      journalctl -u neutron-openvswitch-agent -n 50

  Expected (buggy) result:

      AttributeError: 'NoneType' object has no attribute
  'get_flood_to_tun_ofports'

  and the agent stays down.

  After the patch (confirm the fix):

      # install neutron-openvswitch-agent from -proposed, then record the version
      apt-cache policy neutron-openvswitch-agent
      systemctl restart neutron-openvswitch-agent
      systemctl is-active neutron-openvswitch-agent
      journalctl -u neutron-openvswitch-agent -n 50
      openstack network agent list --agent-type open-vswitch

  Expected (fixed) result:

   * The agent restarts without the AttributeError and reports active.
   * The agent shows alive/UP in "openstack network agent list".
   * Existing instances keep provider-network connectivity across the restart.
   * On a tunneling-enabled (VXLAN/GRE) deployment, restarting the agent still restores the br-tun flood output ports, so east-west traffic between compute nodes continues to work.

  [Where problems could occur]

  If the enable_tunneling guard is evaluated incorrectly on a tunneling-
  enabled deployment, the br-tun flood output ports are not restored on
  agent restart and broadcast or unknown-unicast traffic on tunnel
  networks either stops reaching remote compute nodes or is flooded to
  the wrong ports.

  [Other Info]

  Fixed upstream on master and stable/2026.1 (neutron 28.0.1) by
  https://opendev.org/openstack/neutron/commit/0b06dc038b685f3340c8a7cf7b07128ed5c39b27
  Guard tun_br in _restore_local_vlan_map when no br-tun

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