WARNING juju.apiserver.common.networkingcommon types.go:228 ignoring address ... for device "lo": ... not found

Is the model also updated to the controller's version here?

Can I get the output of "ip a" on one of these machines too?

Yeah, the model is updated to match the controllers version.

| 2021-11-18 22:00:52 WARNING juju.apiserver.common.networkingcommon types.go:228 ignoring address "10.15.190.45" for device "lo": address and CIDR pair ("10.15.190.45", "") not found
| 2021-11-18 22:00:52 WARNING juju.apiserver.common.networkingcommon types.go:228 ignoring address "10.15.190.46" for device "lo": address and CIDR pair ("10.15.190.46", "") not found

| ubuntu@juju-806ee7-stg-proposed-migration-41:~$ ip a
| 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
| link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
| inet 127.0.0.1/8 scope host lo
| valid_lft forever preferred_lft forever
| inet6 ::1/128 scope host
| valid_lft forever preferred_lft forever
| 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
| link/ether fa:16:3e:5f:94:58 brd ff:ff:ff:ff:ff:ff
| inet 10.15.190.45/23 brd 10.15.191.255 scope global dynamic ens3
| valid_lft 81275sec preferred_lft 81275sec
| inet6 fe80::f816:3eff:fe5f:9458/64 scope link
| valid_lft forever preferred_lft forever
| 3: fan-252: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
| link/ether 4e:36:96:19:8f:97 brd ff:ff:ff:ff:ff:ff
| inet 252.22.128.1/8 scope global fan-252
| valid_lft forever preferred_lft forever
| inet6 fe80::4c36:96ff:fe19:8f97/64 scope link
| valid_lft forever preferred_lft forever
| 4: ftun0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master fan-252 state UNKNOWN group default qlen 1000
| link/ether 4e:36:96:19:8f:97 brd ff:ff:ff:ff:ff:ff
| inet6 fe80::4c36:96ff:fe19:8f97/64 scope link
| valid_lft forever preferred_lft forever

| ubuntu@juju-806ee7-stg-proposed-migration-42:~$ ip a
| 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
| link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
| inet 127.0.0.1/8 scope host lo
| valid_lft forever preferred_lft forever
| inet6 ::1/128 scope host
| valid_lft forever preferred_lft forever
| 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
| link/ether fa:16:3e:06:4e:d2 brd ff:ff:ff:ff:ff:ff
| inet 10.15.190.46/23 brd 10.15.191.255 scope global dynamic ens3
| valid_lft 83563sec preferred_lft 83563sec
| inet6 fe80::f816:3eff:fe06:4ed2/64 scope link
| valid_lft forever preferred_lft forever
| 3: fan-252: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
| link/ether 22:13:88:a8:8c:27 brd ff:ff:ff:ff:ff:ff
| inet 252.23.0.1/8 scope global fan-252
| valid_lft forever preferred_lft forever
| inet6 fe80::2013:88ff:fea8:8c27/64 scope link
| valid_lft forever preferred_lft forever
| 4: ftun0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master fan-252 state UNKNOWN group default qlen 1000
| link/ether 22:13:88:a8:8c:27 brd ff:ff:ff:ff:ff:ff
| inet6 fe80::2013:88ff:fea8:8c27/64 scope link
| valid_lft forever pr...

This is being seen due to the churn on prodstack.

Machine agents coming up will update their link-layer devices and addresses. This is being seen so frequently because those agents are bouncing.

I've changed the level to INFO, because it shouldn't really be a warning, but in general we do want to surface when addresses are not assigned to devices.

I've also updated the log lines that indicate the device update activity itself so that we include the source and the model. This will make less of those entries appear to be duplicates.

Logging level to INFO or not, do we care about addresses configured/missing on the loopback interface (device "lo")? It's just added noise. In fact, it might be worth excluding that interface so juju does less saving CPU cycles?

Acknowledged regarding the loopback devices.

I'll have a look at the latest logs now that the detail is refined, and determine a course of action.

Interesting that the addresses are coming from the provider itself.

This should be addressed by:
https://github.com/juju/juju/pull/13625

The instancepoller worker contained fallback logic that would generate (and report) fake NIC devices when the underlying substrate did not implement support for enumerating network interfaces (affects the Azure and Openstack providers)

We have landed the following PRs to address this issue:
- https://github.com/juju/juju/pull/13634 and https://github.com/juju/juju/pull/13658 (Azure)
- https://github.com/juju/juju/pull/13648 (Openstack)

As the above patches made the instancepoller worker's fallback logic redundant, we have removed it via https://github.com/juju/juju/pull/13649.

We needed https://github.com/juju/juju/pull/13716 as a follow up for the O7k provider.