Add support for multiple API VIPs

[Edward Hope-Morley]

The vault charm currently supports configuring a single vip on the api network which can be the "default" or "access" spaces. There are some use cases that might benefit from having the api accessible from more than one network e.g. where a use has deployed a vault consumer e.g. kubernetes, on a different network to that used by the primary network on which the vault service is listening. To achieve this we could allow the charm to be configured with multiple VIPs on different networks (much like charms that relate to hacluster can do) and to enable this we could add an extra space binding e.g. "public".

[Edward Hope-Morley (hopem)]

I've had a look at the charms' code to see what this might entail and one potential way to implement a second binding could be to add a new publish_url method [1] which would provide the url for a second space/binding should it be configured. That way the vault charm can optionally be configured on more than one space such that other charms can consume it without needing to be configured on its primary network.

[1] https://github.com/openstack-charmers/charm-interface-vault-kv/blob/master/provides.py#L45

[Edward Hope-Morley (hopem)]

Patch: https://review.opendev.org/#/c/659781/

[Edward Hope-Morley (hopem)]

interface-vault-kv patch:

https://github.com/openstack-charmers/charm-interface-vault-kv/pull/5

[Dmitrii Shcherbakov (dmitriis)]

It seems to me that Juju could be extended to better support things like this:

https://discourse.jujucharms.com/t/multiple-space-bindings-per-endpoint/1999

[David Ames (thedac)]

Please see https://bugs.launchpad.net/vault-charm/+bug/1843809 which seems to have been caused by the above change.

[Edward Hope-Morley (hopem)]

This is actually fixed and released since the patch in comment #5 landed and is synced into the charm as part of 19.10.