goal state calculation for subordinates seems wrong
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Fix Released
|
High
|
Ian Booth | ||
2.4 |
Fix Released
|
High
|
Ian Booth |
Bug 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. 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-
status: joined
since: 2018-11-05 13:40:07Z
keystone-
status: active
since: 2018-11-05 13:50:48Z
keystone-
status: active
since: 2018-11-05 13:51:00Z
keystone-
status: active
since: 2018-11-05 13:52:53Z
# relation-get -r ha:28 - keystone-
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-
ERROR cannot read settings for unit "keystone-
description: | updated |
Changed in juju: | |
milestone: | none → 2.5-beta1 |
status: | New → Triaged |
importance: | Undecided → High |
assignee: | nobody → Ian Booth (wallyworld) |
Changed in juju: | |
status: | In Progress → Fix Committed |
Changed in juju: | |
status: | Fix Committed → Fix Released |
It sounds like goal state should only show you the local unit and not all
units of the related application if you are container scoped. Otherwise you
wouldn't know whether unit ha/0 ha/1 or ha/2 was the local unit.
John
=:->
On Mon, Nov 5, 2018, 21:30 Liam Young <<email address hidden> wrote:
> Public bug reported: hacluster/ 0: hacluster/ 1: hacluster/ 2: hacluster/ 0 hacluster/ 1 hacluster/ 1" in relation hacluster: ha": unit "keystone- hacluster/ 1": settings
>
> 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-
> status: active
> since: 2018-11-05 13:50:48Z
> keystone-
> status: active
> since: 2018-11-05 13:51:00Z
> keystone-
> status: active
> since: 2018-11-05 13:52:53Z
>
> # relation-get -r ha:28 - keystone-
> 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-
> ERROR cannot read settings for unit "keystone-
> "keystone:ha keystone-
> not found
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
> ** Description changed:
>
> - 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
> + 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
> + keystone/0:
> + status: active
> + since: 2018-11-05 13:43:12Z
> + keystone/1:
> + status: active
> + since: 2018-11-05 13:49:29Z
> + keystone/...