keystone initialize fails if undercloud can't reach overcloud public vip

[Giulio Fidente]

In a fresh installation, when deploying with:

$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isola
tion.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml -e env.yaml
Deploying templates in the directory /usr/share/openstack-tripleo-heat-templates

the post deployment keystone initialization remains stuck as it tries to connect to the overcloud public vip; looks like we shouldn't pass the public param to the occ keystone.initialize [1] as it will be preferred to the host parm [2]

1. https://github.com/openstack/python-tripleoclient/blob/master/tripleoclient/v1/overcloud_deploy.py#L356
2. https://github.com/openstack/os-cloud-config/blob/master/os_cloud_config/keystone.py#L414

[Giulio Fidente (gfidente)]

I am trying to address this from https://review.openstack.org/#/c/238514/

[Giulio Fidente (gfidente)]

I think we should change the three occurrences of (public or host) here https://github.com/openstack/os-cloud-config/blob/master/os_cloud_config/keystone.py into 'host' only, so they never try to use the public ip to connect but only to deploy endpoints

[Mark Chappell (mchappel)]

How much of this gets mooted if/when the initialisation moves into the heat templates directly?

https://review.openstack.org/#/c/230375/

[Tim Rozet (trozet)]

I think the bigger issue with this bug is that the overcloud deploy still returns a success, even though keystone endpoints/users fail to be configured. Should we address that in this bug, or should I open a new one?

[Dan Sneddon (dsneddon)]

I have run into this situation many times. One thing I have noticed is that the Keystone initialize happens in a loop. If I am watching the logs, then I might get a hint, and if I fix the networking fast enough, then Keystone initialization continues.

If there were an informative message spit out that the Keystone Public API cannot be reached, then perhaps the installer could fix it. If the message included the URL of the Keystone Public API, they could try to ping/netcat/etc. to that address and troubleshoot before the deployment timed out.

[Emilien Macchi (emilienm)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, NEWTON, OCATA, PIKE, PIKE).
  Valid example: CONFIRMED FOR: LIBERTY