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: 2023-02-22 23:02 UTC (History)
9 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:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 187205 0 None None None Never
OpenStack gerrit 187262 0 None None None Never
OpenStack gerrit 187450 0 None None None Never
OpenStack gerrit 187472 0 None None None Never
Red Hat Product Errata RHEA-2015:1549 0 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.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.