goal state calculation for subordinates seems wrong

[Liam Young]

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

[John A Meinel (jameinel)]

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:
>
> 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
>
> ** 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/...

[Ian Booth (wallyworld)]

https://github.com/juju/juju/pull/9425