Comment 2 for bug 1981588

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.152.183.208
> + # ...
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1981588
>
> Title:
> [ux] Relation data snapshot on error
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1981588/+subscriptions
>
>