Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1491803

Summary: Floating ip is not reachable on some routers after update due to missing IP on qg- interfaces
Product: Red Hat OpenStack Reporter: Robin Cernin <rcernin>
Component: openstack-neutronAssignee: Jakub Libosvar <jlibosva>
Status: CLOSED DUPLICATE QA Contact: Toni Freger <tfreger>
Severity: medium Docs Contact:
Priority: medium    
Version: 10.0 (Newton)CC: amuller, chrisw, jlibosva, mcornea, nyechiel, panburaj, pmyers, rcernin, srevivo
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-09-25 14:26:33 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 Robin Cernin 2017-09-14 17:51:21 UTC
Description of problem:

After deployment of neutron agents on separated networking nodes we have noticed there was no neutron ml2 plugin configured. However the neutron.conf still used the ml2 as core_driver. We know this might be more of a deployment/director issue, however we were having networking and noticed such configuration in place would not work probably:

The /etc/neutron/neutron.conf contains:

[DEFAULT]
auth_strategy=keystone
core_plugin=ml2

And then if we look at plugins/ml2/ml2_conf.ini it is empty:

# egrep -v "^$|^#" plugins/ml2/ml2_conf.ini
[DEFAULT]
[ml2]
[ml2_type_flat]
[ml2_type_geneve]
[ml2_type_gre]
[ml2_type_vlan]
[ml2_type_vxlan]
[securitygroup]

Then if we check hiera on controller there is the correct configuration for neutron::plugin::ml2 which is the default one and contains openvswitch by default and others:

# grep -A3 "neutron::plugins::ml2" service_configs.yaml 
neutron::plugins::ml2::extension_drivers: ["qos", "port_security"]
neutron::plugins::ml2::flat_networks: ["datacentre"]
neutron::plugins::ml2::mechanism_drivers: [
  "openvswitch"
]
neutron::plugins::ml2::network_vlan_ranges: ["datacentre:1:1000"]
neutron::plugins::ml2::supported_pci_vendor_devs: [
  "15b3:1004",
  "8086:10ca"
]
neutron::plugins::ml2::tenant_network_types: ["vxlan"]
neutron::plugins::ml2::tunnel_id_ranges: ["1:4094"]
neutron::plugins::ml2::type_drivers: ["vxlan", "vlan", "flat", "gre"]
neutron::plugins::ml2::vni_ranges: ["1:4094"]
neutron::purge_config: false
neutron::rabbit_heartbeat_timeout_threshold: 60
neutron::rabbit_password: ****************

Request: Checking the hiera on networking node we see that the neutron::plugins are missing completely, so is it correct that we setup the core_plugin=ml2 and then we actually deploy no ml2 configuration?

Example for the networking node:

# egrep -A3 "neutron::plugins" /etc/puppet/hieradata/service_configs.yaml 
# egrep -A3 "neutron" /etc/puppet/hieradata/service_configs.yaml 
neutron::agents::dhcp::enable_force_metadata: false
neutron::agents::dhcp::enable_isolated_metadata: false
neutron::agents::dhcp::enable_metadata_network: false
neutron::agents::l3::agent_mode: legacy
neutron::agents::l3::external_network_bridge: ''
neutron::agents::l3::router_delete_namespaces: true
neutron::agents::metadata::auth_password: ****************
neutron::agents::metadata::auth_tenant: service
neutron::agents::metadata::auth_url: http://********:35357
neutron::agents::metadata::metadata_ip: "%{hiera(\"nova_metadata_vip\")}"
neutron::agents::metadata::metadata_workers: 
neutron::agents::metadata::shared_secret: ****************
neutron::agents::ml2::ovs::arp_responder: false
neutron::agents::ml2::ovs::bridge_mappings: ["datacentre:br-ex"]
neutron::agents::ml2::ovs::enable_distributed_routing: false
neutron::agents::ml2::ovs::extensions: ["qos"]
neutron::agents::ml2::ovs::firewall_driver: 
neutron::agents::ml2::ovs::l2_population: False
neutron::agents::ml2::ovs::local_ip: ***************
neutron::agents::ml2::ovs::tunnel_types: ["vxlan"]


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

openstack-neutron-9.4.0-2.el7ost.noarch                     Sat Sep  9 02:43:15 2017                                   
openstack-neutron-bigswitch-agent-9.42.7-1.el7ost.noarch    Sat Sep  9 02:43:28 2017                                   
openstack-neutron-bigswitch-lldp-9.42.7-1.el7ost.noarch     Sat Sep  9 02:43:28 2017                                   
openstack-neutron-common-9.4.0-2.el7ost.noarch              Sat Sep  9 02:43:14 2017                                   
openstack-neutron-lbaas-9.2.1-3.el7ost.noarch               Sat Sep  9 02:43:28 2017                                   
openstack-neutron-metering-agent-9.4.0-2.el7ost.noarch      Sat Sep  9 02:43:28 2017                                   
openstack-neutron-ml2-9.4.0-2.el7ost.noarch                 Sat Sep  9 02:43:15 2017                                   
openstack-neutron-openvswitch-9.4.0-2.el7ost.noarch         Sat Sep  9 02:43:24 2017                                   
openstack-neutron-sriov-nic-agent-9.4.0-2.el7ost.noarch     Sat Sep  9 02:43:28 2017                                   
puppet-neutron-9.5.0-3.el7ost.noarch                        Sat Sep  9 02:45:32 2017                                   
python-neutron-9.4.0-2.el7ost.noarch                        Sat Sep  9 02:43:14 2017                                   
python-neutron-lbaas-9.2.1-3.el7ost.noarch                  Sat Sep  9 02:43:15 2017                                   
python-neutron-lib-0.4.0-1.el7ost.noarch                    Thu Jun 15 18:21:45 2017                                   
python-neutron-tests-9.4.0-2.el7ost.noarch                  Sat Sep  9 02:43:28 2017                                   
python-neutronclient-6.0.0-2.el7ost.noarch                  Thu Jun 15 18:20:32 2017

Comment 8 Jakub Libosvar 2017-09-25 14:26:33 UTC
After debugging live on the machine, it turned out routers missing qg- devices weren't processed by full-sync yet but sometimes instances couldn't reach metadata API. This was caused by missing iptables translation rules in qrouter- namespace due to xtables lock issue tracked in bug 1489070. The fix should be available in the next Z.5 release. Closing as dup for now, feel free to re-open in case you still hit the issue after upgrading.

*** This bug has been marked as a duplicate of bug 1489070 ***

Comment 9 Jakub Libosvar 2017-09-25 14:35:29 UTC
I need to correct my previous statement - the fix won't be available in z.5 yet.