vSphere private / external network - lowest numerical wins
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Canonical Juju |
Triaged
|
Medium
|
Unassigned | ||
Bug Description
Full details can be found in the latter half of the following thread (linked to my first post today) @ https:/
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) wrote | #1 |
| Changed in juju: | |
| status: | New → Triaged |
| importance: | Undecided → Medium |
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.