@afreiberger actually gave me an idea on this post about DNS IP’s and so I did a bit of testing.
I swapped around the vSphere switches that were assigned to Juju, so
primary-network: (old) nv-22-jujuinternal --> (now)nv-23-jujuexternal
external-network: (old) nv-23-jujuexternal --> (now)nv-22-jujuinternal
It does appear that on vSphere the Public address of a unit is numerically the lowest available.
As a reminder to save people scrolling up
nv-22-jujuinternal == 10.50.22.0/24
nv-23-jujuexternal == 10.50.23.0/24
># juju model-config | grep network | grep nv
external-network model nv-22-jujuinternal
primary-network model nv-23-jujuexternal
># juju status
Unit Workload Agent Machine Public address Ports Message
haproxy/0* active idle 0 10.50.22.13 80/tcp,443/tcp Unit is ready
landscape-server/0* active idle 1 10.50.22.14
postgresql/0* active idle 2 10.50.22.15 5432/tcp Live master (10.19)
rabbitmq-server/0* active idle 3 10.50.22.16 5672/tcp Unit is ready
But then I thought there may be opportunity for a little more testing, so I swapped around the subnet range associated with each VLAN
Now, back to the original mappings of
primary-network: nv-22-jujuinternal
external-network: nv-23-jujuexternal
nv-22-jujuinternal == 10.50.23.0/24
nv-23-jujuexternal == 10.50.22.0/24
In theory, we should see that even though nv-22-jujuinternal is the primary network and the initial issue was that the primary interface was presented as the “Public address”, if my suspicion of “lowest numerical” is true, then the address associated with the external-network configurable should be presented by units as the public address, which now would be 10.50.22.0/24
Let’s test!
Waiting for address
Attempting to connect to 10.50.23.10:22
Connected to 10.50.23.10
~snip~
api-endpoints: ['10.50.23.10:17070']
># juju deploy landscape-scalable
~snip~
># juju status
Unit Workload Agent Machine Public address Ports Message
haproxy/0* active idle 0 10.50.22.13 Unit is ready
landscape-server/0* active idle 1 10.50.22.14
postgresql/0* active idle 2 10.50.22.15 5432/tcp Live master (10.19)
rabbitmq-server/0* active idle 3 10.50.22.16 5672/tcp Unit is ready
And there we go, lowest numerical wins for the “Public address” on vSphere.
Now, on the downside, haproxy is accessible now on the haproxy decided it didn’t want to expose ports there, but I suspect that’s likely due to the charm not handling multiple interfaces?private-network IP…
Anyway, I think at this point I should probably file an issue report vs. filling up this thread. That’ll be the next thing I go learn how to do.
Thx
stu