Description of problem: Deploying with IPv6 Network Isolation, with Neutron VLAN mode, but Tenant network is IPv6 and Neutron tunneling is not disabled. The Compute service does not run properly, because neutron-openvswitch-agent refuses to run. Version-Release number of selected component (if applicable): OSP-D 7.3 beta How reproducible: 100% Steps to Reproduce: 1. Deploy with IPv6 Network Isolation using a command similar to this: openstack overcloud deploy --templates \ -e $THT/environments/network-isolation-v6.yaml \ -e $THT/environments/net-single-nic-with-vlans.yaml \ -e /home/stack/templates/network-environment.yaml \ --control-scale 3 \ --compute-scale 1 \ --neutron-network-type vlan \ --neutron-tunnel-types vlan Actual results: neutron-openvswitch-agent fails on the Compute nodes Expected results: neutron-openvswitch-agent should run Additional info: The real workaround is to either not have a Tenant VLAN or use IPv4 on the Tenant VLAN when deploying with IPv6. Also, using --neutron-disable-tunneling may work alone, but that is intended to be used when deploying without a Tenant VLAN. Logs: [root@overcloud-compute-0 neutron]# less openvswitch-agent.log 2016-02-18 00:46:01.660 15635 CRITICAL neutron [-] ConfigFileValueError: fd00:fd00:fd00:5000::10 is not an IPv4 address 2016-02-18 00:46:01.660 15635 TRACE neutron Traceback (most recent call last): 2016-02-18 00:46:01.660 15635 TRACE neutron File "/usr/bin/neutron-openvswitch-agent", line 10, in <module> 2016-02-18 00:46:01.660 15635 TRACE neutron sys.exit(main()) 2016-02-18 00:46:01.660 15635 TRACE neutron File "/usr/lib/python2.7/site-packages/neutron/cmd/eventlet/plugins/ovs_neutron_agent.py", line 20, in main 2016-02-18 00:46:01.660 15635 TRACE neutron ovs_neutron_agent.main() 2016-02-18 00:46:01.660 15635 TRACE neutron File "/usr/lib/python2.7/site-packages/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py", line 1736, in main 2016-02-18 00:46:01.660 15635 TRACE neutron q_utils.log_opt_values(LOG) 2016-02-18 00:46:01.660 15635 TRACE neutron File "/usr/lib/python2.7/site-packages/neutron/common/utils.py", line 270, in log_opt_values 2016-02-18 00:46:01.660 15635 TRACE neutron cfg.CONF.log_opt_values(log, std_logging.DEBUG) 2016-02-18 00:46:01.660 15635 TRACE neutron File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2199, in log_opt_values 2016-02-18 00:46:01.660 15635 TRACE neutron _sanitize(opt, getattr(group_attr, opt_name))) 2016-02-18 00:46:01.660 15635 TRACE neutron File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2520, in __getattr__ 2016-02-18 00:46:01.660 15635 TRACE neutron return self._conf._get(name, self._group) 2016-02-18 00:46:01.660 15635 TRACE neutron File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2242, in _get 2016-02-18 00:46:01.660 15635 TRACE neutron value = self._do_get(name, group, namespace) 2016-02-18 00:46:01.660 15635 TRACE neutron File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2283, in _do_get 2016-02-18 00:46:01.660 15635 TRACE neutron raise ConfigFileValueError(str(ve)) 2016-02-18 00:46:01.660 15635 TRACE neutron ConfigFileValueError: fd00:fd00:fd00:5000::10 is not an IPv4 address
To summarize here on request: --> openvswitch doesn't do IPv6 tunneling (reference would be nice to add here, at this point I just have this BZ - is there an existing upstream bug/request for this). Because of this the tenant network, onto which the nova instances will be connected via ovs gre/vxlan tunnels must be IPv4 always, even when we deploy with v6. --> the original reproducer above omits the '--neutron-disable-tunneling' as is pointed out. If it were included the error would not have occurred. However the more general point remains that the deploy default is vxlan tunneling enabled so if v6 is in play for that tenant network, there will be explosions on the compute node as per the description. --> The review at https://code.engineering.redhat.com/gerrit/#/c/67919/ sets the tenant network to the 'normal' v4 template in the network-isolation-v6.yaml environment file (which is used for a v6 deploy)
/usr/share/openstack-tripleo-heat-templates/environments/external-loadbalancer-vip-v6.yaml still contains references to ipv6 tenant networks: grep tenant /usr/share/openstack-tripleo-heat-templates/environments/external-loadbalancer-vip-v6.yaml OS::TripleO::Controller::Ports::TenantPort: ../network/ports/tenant_from_pool_v6.yaml I believe we should change this to reflect the tenat on ipv4 change: OS::TripleO::Controller::Ports::TenantPort: ../network/ports/tenant_from_pool.yaml tenant:
Hi Why don't we just make sure tunnelling is disabled for ipv6 ? when installing ipv6 setup the default will be vlan (maybe add new flag to cli )
(In reply to Ofer Blaut from comment #8) > Hi > > Why don't we just make sure tunnelling is disabled for ipv6 ? when > installing ipv6 setup the default will be vlan (maybe add new flag to cli ) Because there may be valid use cases for an IPv6-based cloud with an IPv4 tunneling network. The TripleO Heat Template fix allows for this to work.
was test by leonid , external LB setup openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation-v6.yaml -e /home/stack/network-environment-v6.yaml --control-scale 3 --compute-scale 1 --neutron-network-type vlan --neutron-tunnel-types vlan --neutron-network-vlan-ranges datacentre:204:215 --neutron-disable-tunneling --timeout 180 --ntp-server clock.redhat.com -e /usr/share/openstack-tripleo-heat-templates/environments/external-loadbalancer-vip-v6.yaml -e external_lb-v6.yaml
also checked when /usr/share/openstack-tripleo-heat-templates/environments/network-isolation-v6.yaml point to OS::TripleO::Network::Tenant: ../network/tenant_v6.yaml openstack-tripleo-heat-templates-0.8.6-123.el7ost.noarch
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://rhn.redhat.com/errata/RHBA-2016-0424.html