Comment 13 for bug 1897115

The reproducer is going to have different behaviour on LXD compared to vSphere.

LXD now has subnet discovery, which affects how network-get works. In particular, the entries in the machine's link-layer device collection have their subnet data resolved so that they can in turn be chosen by space. You can verify this by running "juju subnets".

When I attempt to execute "juju run --unit kubernetes-master/0 -- network-get kube-api-endpoint", I can see controller model logs that look like this:

machine-0: 11:35:50 DEBUG juju.apiserver.uniter Looking for address from [static address "10.161.87.77" of device "eth0" on machine "0" static address "10.1.99.0" of device "flannel.1" on machine "0" loopback address "127.0.0.1" of device "lo" on machine "0" loopback address "::1" of device "lo" on machine "0"] in spaces [0]
machine-0: 11:35:50 DEBUG juju.apiserver.uniter skipping static address "10.1.99.0" of device "flannel.1" on machine "0": not linked to a known subnet (subnet "10.1.99.0/32" not found)

What happens here is that only the non-flannel address is returned - the flannel subnet was not discovered.

On vSphere, there is no subnet discovery so the fallback would tend to indicate that the flannel IP has been set as the machine's preferred private address. Is it possible to verify this? One would need to look at the "machines" collection in Mongo.