vSphere private / external network - lowest numerical wins

[dotalchemy]

Full details can be found in the latter half of the following thread (linked to my first post today) @ https://discourse.charmhub.io/t/primary-network-and-external-network-in-vsphere-deployments/2402/5

Essentially, with the vSphere cloud provider, you must specify both a private-network and an external-network, with the intent being that the private-network is used for communication between deployed machines and the external-network is where one would find the IP that is presenting the service - for example, tcp/80 or tcp/443 on haproxy, or the web interface for juju-gui

From testing, this isn't the case.

The external interface is assigned correctly, as I can go to vCenter and get the "external" network IP of the instance, or I can get it from `juju show-machine x` and paste it to a browser, but `juju status` shows the numerically lowest IP between the two.

For example, if haproxy has 10.50.22.10/24 assigned to the 'private-network' and has 10.50.23.10/24 assigned to the 'external-network', `juju status` will return the numerically lowest of the two and will show 10.50.22.10 as the 'Public address' of the instance, which in theory (and practice here) could be a non-routable address space.

So, for a work-around, we effectively must ensure that our "public address" space / 'external-network' is numerically lower than the private-network address space.

[Joseph Phillips (manadart)]

We know why this happens.

Both subnets are in the class A private range, which Juju designates as having scope "local-cloud".

Since scope differentiation is not possible, we just end up choosing the first lexicographically sorted address.

Until we implement some form of network discovery via the vSphere provider, there isn't a mechanism we can offer the user to make this public/private distinction.