vault is not using vip to communicate with other services

[Ashley Lai]

On the deployment, barbican-vault is communicating with vault using the internal IP instead of the vip.

2020-05-09 19:01:08 INFO juju-log secrets-storage:53: Retrieving secret-id from vault (https://192.168.33.159:8200)

artifacts can be found on the bottom of the link:
https://solutions.qa.canonical.com/#/qa/testRun/d9623788-6774-4cf5-a1a9-df70d510a0c6

[Dmitrii Shcherbakov (dmitriis)]

The log message is from barbican-vault which simply uses a URL from the interface code

https://opendev.org/openstack/charm-barbican-vault/src/commit/5eb8923ec028d9f480fa97f281c54c38c8dc09ef/src/reactive/barbican_vault_handlers.py#L41

The interface code simply passes it through as well:
https://github.com/openstack-charmers/charm-interface-vault-kv/blob/5e71b61c1ddb6ecaade2b6675a5d8cf26655d7b0/requires.py#L92-L98
https://github.com/openstack-charmers/charm-interface-vault-kv/blob/5e71b61c1ddb6ecaade2b6675a5d8cf26655d7b0/provides.py#L41-L60

At the vault side, the content of a published URL depends on whether a relation to charm-hacluster is present or not:

https://opendev.org/openstack/charm-vault/src/commit/324d5f638110876993d6b584e9b2220558049a10/src/reactive/vault_handlers.py#L504-L525

I think it is safe to say that if a VIP is configured and the ha.available flag is not set then we should not expose a URL and wait until ha.available is set.

Triaging based on the above.

[Ashley Lai (alai)]

Submitted to field high as it is blocking SSL deployment.

[David Ames (thedac)]

In progress https://review.opendev.org/#/c/728999/