Bug 1230450 - Instack/Tuskar/OSCPlugin should allow usage of either gre, vxlan or vlan for the tenant networks
Summary: Instack/Tuskar/OSCPlugin should allow usage of either gre, vxlan or vlan for ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-rdomanager-oscplugin
Version: 7.0 (Kilo)
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ga
: Director
Assignee: Marios Andreou
QA Contact: Eran Kuris
URL:
Whiteboard:
: 1223063 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-11 00:06 UTC by Giulio Fidente
Modified: 2015-08-05 13:53 UTC (History)
10 users (show)

Fixed In Version: python-rdomanager-oscplugin-0.0.8-3.el7ost openstack-tripleo-heat-templates-0.8.6-11.el7ost
Doc Type: Enhancement
Doc Text:
This release introduces four parameters that govern the default overcloud neutron tenant network behavior: --neutron-network-type, --neutron-tunnel-types, --neutron-disable-tunneling, and --neutron-network-vlan-ranges. The default is to provide GRE types and tunnels for overcloud tenant networks. If the --neutron-network-type is specified as 'vlan', you can also set the --neutron-network-vlan-ranges parameter, which governs the range of VLAN IDs to be allocated to overcloud Neutron tenant networks (defaults to "datacenter:1:1000", where "datacenter" must be the name of the Neutron physical network where the VLANs will be allocated). If exclusively specifying 'vlan' as the network type, then --neutron-disable-tunneling must also be specified (examples below). If the --neutron-network-type is specified as 'gre' or 'vxlan' (or both), then the corresponding --neutron-tunnel-types must also be enabled (examples below). Furthermore, when specifying the 'gre' or 'vxlan' network types, you can further set the related --neutron-tunnel-id-ranges and --neutron-vni-ranges parameters that govern the GRE or VXLAN tunnel IDs respectively. These are to be made available for the tenant networks. Examples: * Specify the 'vxlan' type for overcloud tenant networks: openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2 --neutron-network-type "vxlan" --neutron-tunnel-types "vxlan" * Specify both 'gre' and 'vxlan' overcloud tenant networks: openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2 --neutron-network-type "gre,vxlan" --neutron-tunnel-types "gre,vxlan" * Specify the 'vlan' type for overcloud tenant networks, as well as the VLAN ranges: openstack overcloud deploy --plan overcloud --control-scale 3 --compute-scale 2 --neutron-network-type "vlan" --neutron-disable-tunneling --neutron-network-vlan-ranges "datacenter:3:3000" These parameters default to the following values when not specified at deployment time, and may be deemed restrictive or unsuitable for a given deployment scenario: --neutron-network-type # default 'gre' --neutron-tunnel-types # default 'gre' --neutron-disable-tunneling # defaults to tunneling being enabled --neutron-network-vlan-ranges # 'datacenter:1:1000' After deployment, you can verify that the following are set in the Neutron configuration logs on a controller node; the values here should correspond to those specified during the deployment as shown above: grep -rni 'tunnel_types\|network_type\|enable_tunneling\|vlan_ranges' /etc/neutron/* /etc/neutron/plugin.ini:14:tenant_network_types = vlan /etc/neutron/plugin.ini:72:network_vlan_ranges =datacenter:3:3000 /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:54:enable_tunneling=False /etc/neutron/plugins/ml2/ml2_conf.ini:14:tenant_network_types = vlan /etc/neutron/plugins/ml2/ml2_conf.ini:72:network_vlan_ranges =datacenter:3:3000 Also, you can create a network in overcloud Neutron and inspect it; for example, on the undercloud: $ source overcloudrc $ neutron net-create "default" $ neutron net-show default ... | provider:network_type | vlan | | provider:physical_network | datacenter | | provider:segmentation_id | 3 | ...
Clone Of:
Environment:
Last Closed: 2015-08-05 13:53:14 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
OpenStack gerrit 187205 None None None Never
OpenStack gerrit 187262 None None None Never
OpenStack gerrit 187450 None None None Never
OpenStack gerrit 187472 None None None Never
Red Hat Product Errata RHEA-2015:1549 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform director Release 2015-08-05 17:49:10 UTC

Description Giulio Fidente 2015-06-11 00:06:39 UTC
We should make it possible for users to select amongst gre, vxlan or vlan for the tenant networks tunneling. Currently gre is used by default.


To use vxlan:

parameters:
  NeutronNetworkType: vxlan
  NeutronTunnelTypes: vxlan


To use vlan:

parameters:
  NeutronNetworkType: vlan
  NeutronEnableTunnelling: false
  NeutronNetworkVLANRanges: datacentre:1:1000

where

- 'datacentre' must be the name of the neutron physical network where the vlans will be allocated (by default we have a single physical network defined in NeutronBridgeMappings)
- 1:1000 is the allocatable range

Comment 3 chris alfonso 2015-06-12 16:39:04 UTC
Gulio, please link your patch in here so we have the docs on how this works.

Comment 4 Giulio Fidente 2015-06-12 16:50:10 UTC
Following changes were pushed to make the three options working correctly in the templates: 

 https://review.openstack.org/#/c/187205/
 https://review.openstack.org/#/c/187450/
 https://review.openstack.org/#/c/187262/

as per report the relevant params are:

  NeutronNetworkType: (can be gre, vxlan or vlan)
  NeutronTunnelTypes: (can be gre or vxlan)
  NeutronEnableTunnelling: (should be false when using vlan type)
  NeutronNetworkVLANRanges: datacentre:1:1000 (the neutron phys network name plus the vlan range to use)

Comment 8 Ana Krivokapic 2015-06-19 17:53:34 UTC
*** Bug 1223063 has been marked as a duplicate of this bug. ***

Comment 10 Eran Kuris 2015-06-30 06:59:43 UTC
VERIFIED :
[stack@instack ~]$  rpm -qa |grep tripleo
openstack-tripleo-image-elements-0.9.6-4.el7ost.noarch
openstack-tripleo-0.0.7-0.1.1664e566.el7ost.noarch
openstack-tripleo-puppet-elements-0.0.1-2.el7ost.noarch
openstack-tripleo-common-0.0.1.dev6-0.git49b57eb.el7ost.noarch
openstack-tripleo-heat-templates-0.8.6-19.el7ost.noarch
[stack@instack ~]$ rpm -qa |grep rdo
rubygem-rdoc-4.0.0-24.el7.noarch
python-rdomanager-oscplugin-0.0.8-13.el7ost.noarch


]$ ssh heat-admin@192.0.2.16
The authenticity of host '192.0.2.16 (192.0.2.16)' can't be established.
ECDSA key fingerprint is 61:df:21:ce:de:b8:14:3d:b6:b0:80:37:f0:32:cc:ed.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.0.2.16' (ECDSA) to the list of known hosts.
Last login: Tue Jun 30 02:51:58 2015 from 192.0.2.1
[heat-admin@overcloud-controller-0 ~]$ 

# tunnel_types =
tunnel_types =vxlan
# Example: tunnel_types = gre
# Example: tunnel_types = vxlan
# Example: tunnel_types = vxlan, gre

Comment 13 errata-xmlrpc 2015-08-05 13:53:14 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/RHEA-2015:1549


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