Bug 1717114 - When switching from NeutronTunnelTypes: 'vxlan' to NeutronTunnelTypes: '' in a cloud that was already deployed, puppet does not unset `agent/tunnel_types`, but it does unset `ovs_local_ip`
Summary: When switching from NeutronTunnelTypes: 'vxlan' to NeutronTunnelTypes: '' in ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: puppet-neutron
Version: 13.0 (Queens)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: z9
: 13.0 (Queens)
Assignee: Brent Eagles
QA Contact: nlevinki
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-04 17:42 UTC by Andreas Karis
Modified: 2020-01-21 16:55 UTC (History)
12 users (show)

Fixed In Version: puppet-neutron-12.4.1-8.el7ost
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-07 14:01:17 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Launchpad 1832251 None None None 2019-06-10 18:26:34 UTC
OpenStack gerrit 666407 None MERGED Ensure tunnel types are absent if not configured 2020-02-20 15:55:08 UTC
Red Hat Knowledge Base (Solution) 3445231 None None After a stack update, neutron shows error message `Tunneling can't be enabled with invalid local_ip 'None'. IP couldn't ... 2019-06-04 17:42:24 UTC
Red Hat Product Errata RHBA-2019:3794 None None None 2019-11-07 14:01:36 UTC

Description Andreas Karis 2019-06-04 17:42:00 UTC
Description of problem:
This is a long standing issue and present in both OSP 10 and OSP 13: https://access.redhat.com/solutions/3445231

When switching from NeutronTunnelTypes: 'vxlan' to NeutronTunnelTypes: '' in a cloud that was already deployed, puppet does not unset `agent/tunnel_types`, but it does unset `ovs_local_ip`. This leads to the following ERROR:
~~~
ERROR neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [-] Tunneling can't be enabled with invalid local_ip 'None'. IP couldn't be found on this host's interfaces.
~~~

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

NeutronTunnelTypes: '' sets the following hieradata:
~~~
/etc/puppet/hieradata/service_configs.yaml:neutron::agents::ml2::ovs::tunnel_types: []
~~~

Which updates local_ip to the default of <None>:
~~~
/etc/neutron/plugins/ml2/openvswitch_agent.ini:#local_ip = <None>
~~~

However, Director keeps the definition for tunnel_types as "vxlan":
~~~
/etc/neutron/plugins/ml2/openvswitch_agent.ini:tunnel_types =vxlan
~~~

This looks like a bug, in /etc/puppet/modules/neutron/manifests/agents/ml2/ovs.pp:
~~~
  if $enable_tunneling_real {
    neutron_agent_ovs {
      'ovs/tunnel_bridge':         value => $tunnel_bridge;
      'ovs/local_ip':              value => $local_ip;
      'ovs/int_peer_patch_port':   value => $int_peer_patch_port;
      'ovs/tun_peer_patch_port':   value => $tun_peer_patch_port;
      'agent/tunnel_types':        value => join($tunnel_types, ',');
    }

    if 'vxlan' in $tunnel_types {
      validate_vxlan_udp_port($vxlan_udp_port)
      neutron_agent_ovs {
        'agent/vxlan_udp_port': value => $vxlan_udp_port;
      }
    }
  } else {
    neutron_agent_ovs {
      'ovs/tunnel_bridge':         ensure => absent;
      'ovs/local_ip':              ensure => absent;
      'ovs/int_peer_patch_port':   ensure => absent;
      'ovs/tun_peer_patch_port':   ensure => absent;
    }
  }
~~~

Looking at the  `else` section, agent/tunnel_types should be set to "ensure => absent". The same issue still exists in OSP 13.

Comment 1 Andreas Karis 2019-06-04 17:43:04 UTC
Affects OSP 10 as well.

Comment 15 Alex McLeod 2019-10-31 11:29:14 UTC
If this bug requires doc text for errata release, please set the 'Doc Type' and provide draft text according to the template in the 'Doc Text' field. The documentation team will review, edit, and approve the text.

If this bug does not require doc text, please set the 'requires_doc_text' flag to -.

Comment 17 errata-xmlrpc 2019-11-07 14:01:17 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, 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-2019:3794


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