Bug 1294775

Summary: The keystone adminURL and internalURL are always created on the ctlplane
Product: Red Hat OpenStack Reporter: Udi Kalifon <ukalifon>
Component: openstack-tripleo-heat-templatesAssignee: Jiri Stransky <jstransk>
Status: CLOSED DUPLICATE QA Contact: Shai Revivo <srevivo>
Severity: high Docs Contact:
Priority: urgent    
Version: 8.0 (Liberty)CC: cylopez, ggillies, hbrock, hjensas, jcoufal, jslagle, kbasil, mburns, mcornea, nkinder, panbalag, rcritten, rhel-osp-director-maint, sclewis
Target Milestone: ---Keywords: Regression
Target Release: 10.0 (Newton)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-02-14 15:56:11 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 Udi Kalifon 2015-12-30 09:34:31 UTC
Description of problem:
In my ServiceNetMap I specify "KeystoneAdminApiNetwork: internal_api", but then when I run "keystone catalog" on the deployed overcloud - I see the adminURL and internalURL on the ctlplane (172.16.x.x in my case, while all other services that are mapped to internal-api are correctly on 10.35.191.x)


Version-Release number of selected component (if applicable):
openstack-tripleo-heat-templates-0.8.7-2.el7ost.noarch


How reproducible:
100%


Steps to Reproduce:
1. Deploy an overcloud with network isolation, and put the KeystoneAdminApiNetwork on the internal_api network
2. Run "keystonre catalog" on the overcloud once it's deployed


Actual results:
The keystone adminURL and internalURL are always created on the ctlplane


Expected results:
The end[points should be on the network they were mapped to


Additional info:
In 7.2 this bug was fixed, but in 8.0 it is happening again.

Comment 3 Mike Burns 2016-04-07 21:03:37 UTC
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.

Comment 6 Rob Crittenden 2017-02-14 15:56:11 UTC

*** This bug has been marked as a duplicate of bug 1383724 ***