Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1117019

Summary: VLAN ID on external network should be dropped from the UI design and mappings
Product: Red Hat OpenStack Reporter: Miguel Angel Ajo <majopela>
Component: rhel-osp-installerAssignee: Scott Seago <sseago>
Status: CLOSED ERRATA QA Contact: Ofer Blaut <oblaut>
Severity: high Docs Contact:
Priority: urgent    
Version: 5.0 (RHEL 7)CC: aberezin, ddomingo, dnavale, hbrock, majopela, nyechiel, rhos-maint, sseago
Target Milestone: ga   
Target Release: Installer   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
When an administrator wants to use single or multiple external networks with VLAN ID, the dashboard interface requests the VLAN mappings information and sets them in the configuration file. As a result, when using the CLI, the user needs to use the same information, else the external network will fail. If the VLAN ID needs to be modified, then the user needs to update the parameter in Foreman. As a fix to this issue: 1. An empty mapping for 'network_vlan_ranges' parameter as "physnet-external" is set as follows: [("physnet-tenants:#{self.tenant_vlan_ranges}" if self.vlan_segmentation?), ("physnet-external")].compact 2. In the Dashboard, '[ ] Use VLAN ID _____ for External Network' is removed. This fix allows the administrator to create an external network to be configured on any VLAN+VID, or a flat external network without VLAN.
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-21 18:05:01 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 Miguel Angel Ajo 2014-07-07 19:57:53 UTC
Description of problem:

We have an option like this, when we ask for external network setup

         [ ] Use VLAN ID _____ for External Network

But, as we are leaving the logical network setup to the user on CLI
or via horizon when that's available there's no reason to ask 
the user for the same parameter twice.

There is a way to tell neutron that we allow VLAN on a physnet, with
any VID.

just change here:

https://github.com/theforeman/staypuft/blob/master/app/models/staypuft/deployment/neutron_service.rb#L153

from:

 def networker_vlan_ranges
      [("physnet-tenants:#{self.tenant_vlan_ranges}" if self.vlan_segmentation?),
       ("physnet-external:#{self.vlan_ranges_for_external_network}" if self.external_network_vlan?)].compact
    end

into: 

    def networker_vlan_ranges
      [("physnet-tenants:#{self.tenant_vlan_ranges}" if self.vlan_segmentation?),
       ("physnet-external")].compact
    end


and then remove this from the UI:
         [ ] Use VLAN ID _____ for External Network


This will allow for the external network to be configured on any 
VLAN+VID, or a flat external network without vlan.

---------------------------


For example, an external network in flat model would be set from cli like:


# neutron net-create ext_net \
                     --provider:network_type flat  \
                     --provider:physical_network physnet-external \
                     --router:external=True

an external network with VLAN on VID 3 would be created like this:

# neutron net-create ext_net \
                     --provider:network_type vlan \
                     --provider:segmentation_id 3 \
                     --provider:physical-network physnet-external \
                     --router:external=True


-------------

The CIDR, and floating ip ranges would be set equally after that:

neutron subnet-create ext_net \
               --allocation-pool start=192.168.2.100,end=192.168.2.222 \
               --gateway=192.168.2.1 \
               --enable_dhcp=False \
               192.168.2.0/24 \
               --name ext_subnet

Comment 1 Miguel Angel Ajo 2014-07-07 20:00:50 UTC
The problem with the current design, and this is why it's important, is that if the UI setting (& underlying mapping) and what user sets in CLI/API later don't match, it won't work.

Comment 3 Scott Seago 2014-07-08 13:16:50 UTC
To clarify, rather than conditionally adding the second entry for "physnet-external" with VLAN ID specified, we will *always* add "physnet-external" (but without VLAN ID) ?

Comment 4 Scott Seago 2014-07-08 17:04:10 UTC
PR posted for fix:

https://github.com/theforeman/staypuft/pull/185

Comment 5 Miguel Angel Ajo 2014-07-08 20:01:16 UTC
Scott, sorry I didn't reply your question in comment 3, correct, Unconditionally adding the physnet-external mapping does the job.

Your pull request looks good.

Comment 6 Scott Seago 2014-07-09 00:22:01 UTC
PR has been merged on the master branch.

Comment 15 Ofer Blaut 2014-08-12 11:08:56 UTC
verified - rhel-osp-installer-0.1.9-1.el6ost.noarch

Also relate to bug https://bugzilla.redhat.com/show_bug.cgi?id=1129227

Comment 16 errata-xmlrpc 2014-08-21 18:05:01 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.

http://rhn.redhat.com/errata/RHBA-2014-1090.html