unit network data not populated on peer relations in sidecar charms

[Jon Seager]

When adding units to charms that use peer relations, they don't see to be inheriting the default unit data for ingress-address, egress-subnet, private-address etc. in the relation data

I put together a demo charm (https://github.com/jnsgruk/charm-demo-peer-relation), if you build and deploy it, then scale it and watch the debug log, it outputs something similar to this when it is scaled up/down

```
Unit peer-relation-demo/0 can see the following data: KeysView({<ops.model.Unit peer-relation-demo/0>: {}, <ops.model.Application peer-relation-demo>: {'leader-ip': '10.1.215.247'}})
```

I added the same logger instruction to a pod_spec charm (mongodb-operator) to test the behaviour, and each of the units get data like the following on the peer relation by default:

```
mongodb/0 can see the following KeysView({<ops.model.Unit mongodb/0>: {'egress-subnets': '10.152.183.206/32', 'ingress-address': '10.152.183.206', 'private-address': '10.152.183.206'}, <ops.model.Application mongodb>: {}, <ops.model.Unit mongodb/2>: {'egress-subnets': '10.152.183.206/32', 'ingress-address': '10.152.183.206', 'private-address': '10.152.183.206'}, <ops.model.Unit mongodb/1>: {'egress-subnets': '10.152.183.206/32', 'ingress-address': '10.152.183.206', 'private-address': '10.152.183.206'}})
```

It seems that sidecar charms are not populated with the juju-info implicit relation fields

[Jon Seager (jnsgruk)]

Line in the demo charm that is dumping the relation data: https://github.com/jnsgruk/charm-demo-peer-relation/blob/29422d263b20309d223b5020b26363eae316c8d1/src/charm.py#L74

[Joseph Phillips (manadart)]

Reproduced.

I can see that we emit the "joined relation..." message, which implies a successful call to EnterScope where these settings should be populated.

Still delving.

[Joseph Phillips (manadart)]

The the relation network info set by EnterScope comes from the service addresses (cloud-local). But there are no addresses there.

juju:PRIMARY> db.cloudservices.find({"_id" : "7e927814-a27a-4616-824d-17685b272d06:a#peer-relation-demo"}).pretty()
{
        "_id" : "7e927814-a27a-4616-824d-17685b272d06:a#peer-relation-demo",
        "provider-id" : "",
        "addresses" : [ ],
        "generation" : NumberLong(0),
        "desired-scale-protected" : true,
        "model-uuid" : "7e927814-a27a-4616-824d-17685b272d06",
        "txn-revno" : NumberLong(2),
        "txn-queue" : [
                "60658966fe5c05001d940a3b_fa54b797"
        ]
}

Only the container addresses have been populated.

juju:PRIMARY> db.cloudcontainers.find().pretty()
{
        "_id" : "7e927814-a27a-4616-824d-17685b272d06:u#peer-relation-demo/0#charm",
        "provider-id" : "peer-relation-demo-0",
        "address" : {
                "value" : "10.1.124.185",
                "addresstype" : "ipv4",
                "networkscope" : "local-machine",
                "origin" : "provider"
        },
        "ports" : [ ],
        "model-uuid" : "7e927814-a27a-4616-824d-17685b272d06",
        "txn-revno" : NumberLong(15),
        "txn-queue" : [
                "6065898afe5c05001d940c11_3ac5d11a"
        ]
}
{
        "_id" : "7e927814-a27a-4616-824d-17685b272d06:u#peer-relation-demo/1#charm",
        "provider-id" : "peer-relation-demo-1",
        "address" : {
                "value" : "10.1.124.166",
                "addresstype" : "ipv4",
                "networkscope" : "local-machine",
                "origin" : "provider"
        },
        "ports" : [ ],
        "model-uuid" : "7e927814-a27a-4616-824d-17685b272d06",
        "txn-revno" : NumberLong(7),
        "txn-queue" : [
                "6065898afe5c05001d940c11_3ac5d11a"
        ]
}

I will kick it over to Harry in case he can glean the issue easily.

[Joseph Phillips (manadart)]

I marked this as fix-committed, because I deployed Ben's ol' trusty snappass-test and saw that it gets an address in the "cloudservices" collection, and so assumed we had made a fix.

But now I redeployed your test charm and saw that it does not.

So this must be an artefact of the charm. If you can fill the gap between these two charms so that that charm-demo-peer-relation populates the service data, I believe it will be able to access the network data via the peer relation.

[Joseph Phillips (manadart)]

After talking with the observability charming team, I have what I am told are reproducers of this issue, so I'll be digging in a bit deeper.

[Canonical Juju QA Bot (juju-qa-bot)]

I suspect the root cause here is as per https://bugs.launchpad.net/bugs/1930649

There's a PR to fix the above bug
https://github.com/juju/juju/pull/13049

Hopefully retesting with the above fix will show it's solved.