Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
First Last Prev Next    This bug is not in your last search results.
Bug 1230450 - Instack/Tuskar/OSCPlugin should allow usage of either gre, vxlan or vlan for the tenant networks
Instack/Tuskar/OSCPlugin should allow usage of either gre, vxlan or vlan for ...
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-rdomanager-oscplugin (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
high Severity unspecified
: ga
: Director
Assigned To: Marios Andreou
Eran Kuris
: Triaged
: 1223063 (view as bug list)
Depends On:
Blocks:
  Show dependency tree / graph
 
Reported: 2015-06-10 20:06 EDT by Giulio Fidente
Modified: 2015-08-05 09:53 EDT (History)
10 users (show)

See Also:
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 | ...
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-05 09:53:14 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)


External Trackers
Tracker 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 13:49:10 EDT

  None (edit)
Description Giulio Fidente 2015-06-10 20:06:39 EDT 
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 12:39:04 EDT 
Gulio, please link your patch in here so we have the docs on how this works.
Comment 4 Giulio Fidente 2015-06-12 12:50:10 EDT 
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 13:53:34 EDT 
*** Bug 1223063 has been marked as a duplicate of this bug. ***
Comment 10 Eran Kuris 2015-06-30 02:59:43 EDT 
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 09:53:14 EDT 
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.
First Last Prev Next    This bug is not in your last search results.