| 2018-11-05 17:24:41 |
Liam Young |
description |
The output of goal state does not expose the scope of the relations so there is no way to tell if a relation is container scoped. This is important because a principle charm only has a relation with the local unit of the subordinate. eg
# goal-state
units:
keystone/0:
status: active
since: 2018-11-05 13:43:12Z
keystone/1:
status: active
since: 2018-11-05 13:49:29Z
keystone/2:
status: active
since: 2018-11-05 13:48:28Z
relations:
ha:
keystone-hacluster:
status: joined
since: 2018-11-05 13:40:07Z
keystone-hacluster/0:
status: active
since: 2018-11-05 13:50:48Z
keystone-hacluster/1:
status: active
since: 2018-11-05 13:51:00Z
keystone-hacluster/2:
status: active
since: 2018-11-05 13:52:53Z
# relation-get -r ha:28 - keystone-hacluster/0
clustered: "yes"
egress-subnets: 10.5.0.21/32
ingress-address: 10.5.0.21
private-address: 10.5.0.21
# relation-get -r ha:28 - keystone-hacluster/1
ERROR cannot read settings for unit "keystone-hacluster/1" in relation "keystone:ha keystone-hacluster:ha": unit "keystone-hacluster/1": settings not found |
The output of goal state does not expose the scope of the relations so there is no way to tell if a relation is container scoped. This is important because a principle charm only has a relation with the local unit of the subordinate. This in turn causes issues when a charm tries
to check that all the units it is expecting to be related to have
come up and are ready.
Obviously you could argue that the code consuming the output from goal-state could cross-reference against its local metadata.yaml to get the scope.
eg
# goal-state
units:
keystone/0:
status: active
since: 2018-11-05 13:43:12Z
keystone/1:
status: active
since: 2018-11-05 13:49:29Z
keystone/2:
status: active
since: 2018-11-05 13:48:28Z
relations:
ha:
keystone-hacluster:
status: joined
since: 2018-11-05 13:40:07Z
keystone-hacluster/0:
status: active
since: 2018-11-05 13:50:48Z
keystone-hacluster/1:
status: active
since: 2018-11-05 13:51:00Z
keystone-hacluster/2:
status: active
since: 2018-11-05 13:52:53Z
# relation-get -r ha:28 - keystone-hacluster/0
clustered: "yes"
egress-subnets: 10.5.0.21/32
ingress-address: 10.5.0.21
private-address: 10.5.0.21
# relation-get -r ha:28 - keystone-hacluster/1
ERROR cannot read settings for unit "keystone-hacluster/1" in relation "keystone:ha keystone-hacluster:ha": unit "keystone-hacluster/1": settings not found |
|
