goal state calculation for subordinates seems wrong

Bug #1801765 reported by Liam Young on 2018-11-05
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
juju
High
Ian Booth
2.4
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-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

Liam Young (gnuoy) on 2018-11-05
description: updated
Download full text (4.7 KiB)

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

Read more...

Ian Booth (wallyworld) on 2018-11-08
Changed in juju:
milestone: none → 2.5-beta1
status: New → Triaged
importance: Undecided → High
assignee: nobody → Ian Booth (wallyworld)
Ian Booth (wallyworld) wrote :
Changed in juju:
status: Triaged → In Progress
Ian Booth (wallyworld) on 2018-11-09
Changed in juju:
status: In Progress → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers