Note the unit id "remote-814c01e71f384b588d930775258f7fda"
However the vaultlocker code is checking for the local unit name [0] i.e. nova-compute/0:
for relation_id in hookenv.relation_ids(self.interfaces[0]):
for unit in hookenv.related_units(relation_id): data = hookenv.relation_get(unit=unit, rid=relation_id) vault_url = data.get('vault_url') role_id = data.get('{}_role_id'.format(hookenv.local_unit())) token = data.get('{}_token'.format(hookenv.local_unit()))
I suspect but I have not yet proven that barbican-vault is also broken regardless of its workload status as the interface does the same as above [1]
"good news"/bad news we can reproduce it. It is in fact, a CMR bug. And it is in effect a Not Implmented problem.
A fairly simple deploy scenario using func tests for vault and for nova-compute in separate models:
juju offer zaza-ead92f1cca cb.vault: secrets zaza-ead92f1cca cb.vault" ead92f1ccacb. vault remote-vault
Application "vault" endpoints [secrets] available at "admin/
juju consume admin/zaza-
juju add-relation remote-vault nova-compute
nova-compute has state Incomplete relations: vault
Because this is a test env I can post the relation data:
root@juju- ae180b- zaza-4cf922063f 1a-5:/var/ lib/juju/ agents/ unit-nova- compute- 0/charm# relation-get -r secrets-storage:27 - remote-vault/0 10.5.150. 39:8200"' ae180b- zaza-4cf922063f 1a-5:/var/ lib/juju/ agents/ unit-nova- compute- 0/charm# relation-get -r secrets-storage:27 - remote-vault/1 10.5.150. 39:8200"' ae180b- zaza-4cf922063f 1a-5:/var/ lib/juju/ agents/ unit-nova- compute- 0/charm# relation-get -r secrets-storage:27 - remote-vault/2 814c01e71f384b5 88d930775258f7f da/0_role_ id: '"ace609a5- d182-aeff- 4bdc-53763d5009 82"' 814c01e71f384b5 88d930775258f7f da/0_token: '"s.UHS92pcut8M ExrjPKcggVvPk" ' 10.5.150. 39:8200"'
egress-subnets: 10.5.0.61/32
ingress-address: 10.5.0.61
private-address: 10.5.0.61
vault_url: '"http://
root@juju-
egress-subnets: 10.5.0.72/32
ingress-address: 10.5.0.72
private-address: 10.5.0.72
vault_url: '"http://
root@juju-
egress-subnets: 10.5.0.25/32
ingress-address: 10.5.0.25
private-address: 10.5.0.25
remote-
remote-
vault_url: '"http://
Note the unit id "remote- 814c01e71f384b5 88d930775258f7f da"
However the vaultlocker code is checking for the local unit name [0] i.e. nova-compute/0: relation_ ids(self. interfaces[ 0]): related_ units(relation_ id):
data = hookenv. relation_ get(unit= unit,
rid=relation_ id)
vault_ url = data.get( 'vault_ url')
role_ id = data.get( '{}_role_ id'.format( hookenv. local_unit( )))
token = data.get( '{}_token' .format( hookenv. local_unit( )))
for relation_id in hookenv.
for unit in hookenv.
I suspect but I have not yet proven that barbican-vault is also broken regardless of its workload status as the interface does the same as above [1]
[0] https:/ /github. com/juju/ charm-helpers/ blob/master/ charmhelpers/ contrib/ openstack/ vaultlocker. py#L64 /github. com/openstack- charmers/ charm-interface -vault- kv/blob/ master/ requires. py#L72
[1] https:/