Bug 1258988 - Controller default route is set one provisioning network when using the default single-nic-with-vlan templates
Controller default route is set one provisioning network when using the defau...
Status: CLOSED CURRENTRELEASE
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
high Severity high
: ---
: 7.0 (Kilo)
Assigned To: Dan Sneddon
yeylon@redhat.com
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-01 12:44 EDT by Marius Cornea
Modified: 2016-04-18 03:02 EDT (History)
4 users (show)

See Also:
Fixed In Version: 7.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-04 19:05:40 EST
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)
net dhcp (2.45 KB, text/plain)
2015-09-01 12:44 EDT, Marius Cornea
no flags Details

  None (edit)
Description Marius Cornea 2015-09-01 12:44:12 EDT
Created attachment 1069084 [details]
net dhcp

Description of problem:
When using the default single-nic-with-vlan templates the default route on the controller is set via the provisioning network, on the br-ex device. I'd expect it to be set via the IP address set in ExternalInterfaceDefaultRoute parameter via vlan10 device as specified in the controller template. 

Version-Release number of selected component (if applicable):
os-net-config-0.1.4-2.el7ost.noarch

How reproducible:
100%

Steps to Reproduce:
1. Deploy overcloud with the default single-nic-with-vlan
2. Check default on controller by running 'ip r'

Actual results:
Default route is set via provisioning network.

Expected results:
Default route should be set via the external network.

Additional info:
It looks to me that metric only gets set on individual interface, not when dhcp requests come via the bridge. See the attachment.
Comment 4 Dan Sneddon 2015-12-08 16:32:55 EST
This bug was fixed in OSP-Director 7.1. The fix was to move to static IP addresses on the control plane.

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