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/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
> -
> +   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
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1801765
>
> Title:
>   goal state calculation for subordinates seems wrong
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1801765/+subscriptions
>