Bug 1230450
| Summary: | Instack/Tuskar/OSCPlugin should allow usage of either gre, vxlan or vlan for the tenant networks | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Giulio Fidente <gfidente> |
| Component: | python-rdomanager-oscplugin | Assignee: | Marios Andreou <mandreou> |
| Status: | CLOSED ERRATA | QA Contact: | Eran Kuris <ekuris> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | high | ||
| Version: | 7.0 (Kilo) | CC: | calfonso, dmatthew, jslagle, lnatapov, mburns, rbiba, rhel-osp-director-maint, sclewis, tfreger |
| Target Milestone: | ga | Keywords: | Triaged |
| Target Release: | Director | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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 13:53:14 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
Giulio Fidente
2015-06-11 00:06:39 UTC
Gulio, please link your patch in here so we have the docs on how this works. 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) *** Bug 1223063 has been marked as a duplicate of this bug. *** 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 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 |