[ux] Relation data snapshot on error

[Dmitrii Shcherbakov]

Whenever a hook error happens, it would be useful to automatically save a snapshot of controller data that a unit has retrieved from the agent's PoV. That would make it possible to observe the exact state snapshot that triggered an error. I recognize that this will not capture the state of a unit's host but that can be analyzed via other means.

The snapshot could be similar to what is possible to display via `juju show-unit <unit>`:
juju show-unit etcd-operator/0
etcd-operator/0:
  opened-ports: []
  charm: local:focal/etcd-operator-28
  leader: true
  life: alive
  relation-info:
  - relation-id: 41
    endpoint: cluster
    related-endpoint: cluster
    application-data:
      cluster-token: 2c5c4b2e-5447-4376-ba4f-e9d90a6beb21
      peer-urls: '{"etcd-operator-1": "https://etcd-operator-1.etcd-operator-endpoints.skydive.svc.cluster.local:2380",
        "etcd-operator-2": "https://etcd-operator-2.etcd-operator-endpoints.skydive.svc.cluster.local:2380",
        "etcd-operator-0": "https://etcd-operator-0.etcd-operator-endpoints.skydive.svc.cluster.local:2380"}'
    local-unit:
      in-scope: true
      data:
        egress-subnets: 10.152.183.208/32
        ingress-address: 10.152.183.208
        peer-url: https://etcd-operator-0.etcd-operator-endpoints.skydive.svc.cluster.local:2380
        private-address: 10.152.183.208
# ...

[John A Meinel (jameinel)]

Are you aware that `juju show-unit foo/0` will report the relation data as
seen from that unit? (it doesn't show the data that the unit is telling
others, but does give you the values that the unit is seeing)

On Wed, Jul 13, 2022 at 10:00 AM Dmitrii Shcherbakov <
<email address hidden>> wrote:

> ** Summary changed:
>
> - [ux] Ability to easily show relation data
> + [ux] Relation data snapshot on error
>
> ** Description changed:
>
> - A common repetitive task when debugging charms (in my experience) is
> - getting relation data bag contents.
> -
> - While it is possible to do something like this:
> -
> - # juju run --unit etcd-operator/0 'relation-ids cluster'
> - cluster:41
> -
> - # juju run --unit etcd-operator/0 'relation-get -r 41 - etcd-operator/1'
> - egress-subnets: 10.152.183.208/32
> - ingress-address: 10.152.183.208
> - peer-url:
> https://etcd-operator-1.etcd-operator-endpoints.skydive.svc.cluster.local:2380
> - private-address: 10.152.183.208
> -
> - it seems like a Juju client command to dump a snapshot of relation data
> - (and server side unit state data) at a particular point in time from the
> - point of view of a given unit would be useful.
> -
> - This may also be useful for integration QA runs so that this data can be
> - collected as well and included for charm engineering teams to resolve
> - issues faster. The relation data state is often needed to simulate the
> - problematic case without being able to reproduce it as it may be
> - difficult to trigger it due to timing, environment specifics or other
> - reasons.
> -
> - Likewise, whenever a hook error happens, it would be useful to save a
> - snapshot of controller data that a unit has retrieved from the agent's
> + Whenever a hook error happens, it would be useful to automatically save
> + a snapshot of controller data that a unit has retrieved from the agent's
> PoV. That would make it possible to observe the exact state snapshot
> that triggered an error. I recognize that this will not capture the
> state of a unit's host but that can be analyzed via other means.
> +
> + The snapshot could be similar to what is possible to display via `juju
> show-unit <unit>`:
> + juju show-unit etcd-operator/0
> + etcd-operator/0:
> + opened-ports: []
> + charm: local:focal/etcd-operator-28
> + leader: true
> + life: alive
> + relation-info:
> + - relation-id: 41
> + endpoint: cluster
> + related-endpoint: cluster
> + application-data:
> + cluster-token: 2c5c4b2e-5447-4376-ba4f-e9d90a6beb21
> + peer-urls: '{"etcd-operator-1": "
> https://etcd-operator-1.etcd-operator-endpoints.skydive.svc.cluster.local:2380
> ",
> + "etcd-operator-2": "
> https://etcd-operator-2.etcd-operator-endpoints.skydive.svc.cluster.local:2380
> ",
> + "etcd-operator-0": "
> https://etcd-operator-0.etcd-operator-endpoints.skydive.svc.cluster.local:2380
> "}'
> + local-unit:
> + in-scope: true
> + data:
> + egress-subnets: 10.152.183.208/32
> + ingress-address: 10.152.183.208
> + peer-url:
> https://etcd-operator-0.etcd-operator-endpoints.skydive.svc.cluster.local:2380
> + private-address: 10.15...

[Dmitrii Shcherbakov (dmitriis)]

John, I realized that after I created this LP and changed the description to only include the latter part about the values at the time of an error (the bug notification you got over e-mail has the old description).