Bug 1274687 - Director requires access to the PublicAPI network when using network isolation
Director requires access to the PublicAPI network when using network isolation
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation (Show other bugs)
7.0 (Kilo)
All Linux
high Severity high
: ---
: 10.0 (Newton)
Assigned To: RHOS Documentation Team
RHOS Documentation Team
: Documentation
Depends On:
  Show dependency treegraph
Reported: 2015-10-23 07:15 EDT by Jaison Raju
Modified: 2017-06-07 17:46 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
There is currently a known requirement that can arise when Director connects to the Public API to complete the final configuration post-deployment steps: The Undercloud node must have a route to the Public API, and it must be reachable on the standard OpenStack API ports and port 22 (SSH). To prepare for this requirement, check that the Undercloud will be able to reach the External network on the controllers, as this network will be used for post-deployment tasks. As a result, the Undercloud can be expected to successfully connect to the Public API after deployment, and perform final configuration tasks. These tasks are required in order for the newly created deployment to be managed using the Admin account.
Story Points: ---
Clone Of:
Last Closed: 2017-06-02 00:16:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1509148 None None None Never

  None (edit)
Description Jaison Raju 2015-10-23 07:15:40 EDT
Description of problem:
Director fails after deploying the Heat stack because the Overcloud assumes the Director machine has access to the Internal API network:

undercloud$ openstack overcloud deploy --templates ~/templates/my-overcloud --ntp-server  --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph --control-scale 3 --comp
ute-scale 1 --ceph-storage-scale 3 --neutron-tunnel-types vxlan --neutron-network-type vxlan -e ~/templates/my-overcloud/environments/storage-environment.yaml -e ~/templates/my-overcloud/environments/network-iso
lation.yaml -e ~/templates/my-overcloud/environments/net-multiple-nic-with-vlans.yaml                                                                                                                              
Deploying templates in the directory /home/stack/templates/my-overcloud
/home/stack/.ssh/known_hosts updated.
Original contents retained as /home/stack/.ssh/known_hosts.old
PKI initialization in init-keystone is deprecated and will be removed.
ssh: connect to host port 22: Connection timed out
ERROR: openstack Command '['ssh', '-oStrictHostKeyChecking=no', '-t', '-l', 'heat-admin', u'', 'sudo', 'keystone-manage', 'pki_setup', '--keystone-user', "$(getent passwd | grep '^keystone' | cut -d: -f1)", '--keystone-group', "$(getent group | grep '^keystone' | cut -d: -f1)"]' returned non-zero exit status 255

The problem is that the Director is trying to reach to Overcloud's Keystone over its internal address:

[heat-admin@overcloud-controller-0 ~]$ source overcloudrc 
[heat-admin@overcloud-controller-0 ~]$ keystone endpoint-list
/usr/lib/python2.7/site-packages/keystoneclient/shell.py:65: DeprecationWarning: The keystone CLI is deprecated in favor of python-openstackclient. For a Python library, continue using python-keystoneclient.
  'python-keystoneclient.', DeprecationWarning)
|                id                |   region  |            publicurl            |         internalurl          |            adminurl           |            service_id            |
| 419292fdc1c643e4bcf956032f269956 | regionOne | | | | 9f2ea32571694542b4bf6645c2fe1130 |

Version-Release number of selected component (if applicable):
RHEL OSP Director 7.0 / 7.1 

How reproducible:

Steps to Reproduce:

Actual results:
Heat stack is created but Director is trying to reach to Overcloud's Keystone over its internal address.
This not what is documented / expected.

Expected results:
Either Director do not use / try to communicate over internalapi network or document otherwise of what all networks director needs access to .

Additional info:
documentation doesn't mention this requirement al all. Reading Director documentation , it specifically states this about the Internal API network:
"The Internal API network is used for communication between the OpenStack services via API communication, RPC messages, and database communication. Used by: Controller, Compute, Cinder Storage, Swift Storage"
Comment 4 chris alfonso 2015-10-23 12:07:23 EDT
Dan, would you mind providing some doc text that access to the public api is necessary.
Comment 7 Mike Burns 2016-04-07 16:54:03 EDT
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.
Comment 9 Lucy Bopf 2017-06-02 00:16:26 EDT
This known issue was published in the RHOSP 10 Release Notes here:



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