Comment 9 for bug 1473069

Tested with 1.24.7 and the issue persists.

The order of deployment may matter.
In my example deployment:

1) I deploy the machines I need using juju add-machine or a suitable bundle, and I add 1 container to each server.
2) I then terminate-machine each created container.
3) I modify the NIC configuration to add bridges for each of the physical NICs.
4) I then modify the juju-trusty-lxc-template config file to add the additional NICs to /var/lib/lxc/juju-trusty-lxc-template/config
5) I then also add a dhcp configuration for each additional NIC in /var/lib/lxc/juju-trusty-lxc-template/rootfs/etc/network/interfaces.d/
6) I then continue the juju-deployment with a bundle to deploy the containers on each host.

The deployment succeeds but the IP addresses selected are IP addresses that are not on the management network, but one of the additional networks.

As this is an Openstack deployment, this ends up with containers on the data network and the physical and KVM virtual machines on the management network, preventing internal communication of Openstack components.

So, my deployment example adds the additional NIC configuration before deployment of the LXC containers and not adding the configuration post deployment.

The selection if which IP is the primary on a container in a MAAS environment should be based on which IP is associated with eth0 and not determined by the nature of the IP address itself. The management network in a MAAS environment would typically be a private network address and not a publicly accessible IP address.