Juju unable to interact consistently with an openstack deployment where tenant has multiple networks configured

If there's a reason this should be of a higher priority, please let us know.

We are currently moving all of our testing activities for openstack onto openstack (yes - openstack on openstack) and for some test scenarios we need multiple networks; I don't need explicit support for multiple networks (much bigger piece) but having juju mirror what openstack does for network interface ordering would be helpful.

We just ran face first into this on Canonistack when we enabled a 2nd network. Openstack defaults to allocating IPs on *all* networks even if this isn't what you want and as James said, the Ubuntu cloud images, only configure the first interface.

This just hit us as well, and we were not using quantum for networking. It just so happens that the instance was launched with network interfaces on two networks:

+--------------------------------------+-----------------------------+--------+--------------------------------------------+
| ID | Name | Status | Networks |
+--------------------------------------+-----------------------------+--------+--------------------------------------------+
| 6f4d6b79-51bb-4455-8b3c-ebbff9fafd2e | juju-canonistack2-machine-0 | ACTIVE | canonistack=10.55.63.119; lcy02=10.55.32.3 |
+--------------------------------------+-----------------------------+--------+--------------------------------------------+

Then juju tried to connect to 10.55.32.3 one, but nothing was listening there. The instance doesn't even have a second interface to grab that ip.

Seems to be this code here in state/api/apiclient.go:
func Open(info *Info, opts DialOpts) (*State, error) {
    // TODO Select a random address from info.Addrs
    // and only fail when we've tried all the addresses.
    // TODO what does "origin" really mean, and is localhost always ok?
    cfg, err := websocket.NewConfig("wss://"+info.Addrs[0]+"/", "http://localhost/")

It always grabs the first address, whatever it is.

Given this issue is blocking progress and the importance stated in the comments, can we get it re-prioritized please?

On the OpenStack side you have the "default_floating_pool" options in nova.conf that could help you.

With the fix for bug 1241674 this issue can be avoided by specifying a network with the new config option. That ensures juju machines will only attempt to join one network, so cloud-init and juju-core have no disagreement about which of several is actually in use.

A more comprehensive fix, for cases where people actually want juju machines communicating on multiple networks, will require more network-aware support in juju which is planned but not yet implemented.

Re-targeting for Juju 2.x

This bug has not been updated in 5 years, so we're marking it Expired. If you believe this is incorrect, please update the status.