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

Bug #1188126 reported by James Page on 2013-06-06
62
This bug affects 11 people
Affects Status Importance Assigned to Milestone
juju
Wishlist
Unassigned
juju-core
Medium
Unassigned
pyjuju
Low
Unassigned

Bug Description

When using Juju with an OpenStack deployment using Quantum, with two networks configured for the tenant in use, Juju was not able to consistently determine which network interface/ip address was the 'correct' one to use.

This is due to inconsistency between how OpenStack orders network interfaces when not specified (using the quantum network id) and how Juju orders them when picking from multiple networks (it sorts using the name and picks the first).

As the ubuntu cloud images only configure the first network interface, this can leave an environment in an inaccessible state.

Using the quantum API would allow juju to interrogate the network information and use the same algorithm as openstack to determine ordering.

James Page (james-page) on 2013-06-06
summary: - Juju unable to interact correctly with OpenStack deployment where tenant
- has multiple networks
+ Juju unable to interact consistently with OpenStack/Quantum deployment
+ where tenant has multiple networks configured

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

Changed in juju-core:
status: New → Triaged
importance: Undecided → Wishlist
James Page (james-page) wrote :

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.

James Troup (elmo) wrote :

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.

tags: added: canonistack
Andreas Hasenack (ahasenack) wrote :

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.

summary: - Juju unable to interact consistently with OpenStack/Quantum deployment
- where tenant has multiple networks configured
+ Juju unable to interact consistently with an openstack deployment where
+ tenant has multiple networks configured
tags: added: serverstack
Dean Henrichsmeyer (dean) wrote :

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

Patrick Hetu (patrick-hetu) wrote :

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

tags: added: openstack
Mark Ramm (mark-ramm) on 2013-08-15
Changed in juju-core:
importance: Wishlist → High
Curtis Hovey (sinzui) on 2013-10-12
Changed in juju:
status: New → Triaged
importance: Undecided → Low
Curtis Hovey (sinzui) on 2013-11-27
tags: added: openstack-provider
removed: openstack
Mark Ramm (mark-ramm) on 2014-01-14
Changed in juju-core:
milestone: none → 1.17.1
assignee: nobody → Martin Packman (gz)
Martin Packman (gz) on 2014-01-23
Changed in juju-core:
milestone: 1.17.1 → 1.18.0
Chris J Arges (arges) on 2014-02-10
tags: added: cts-cloud-review
Martin Packman (gz) wrote :

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.

Changed in juju-core:
milestone: 1.20.0 → next-stable
Curtis Hovey (sinzui) on 2014-07-04
Changed in juju-core:
assignee: Martin Packman (gz) → nobody
John A Meinel (jameinel) on 2014-11-06
Changed in juju-core:
milestone: 1.21 → 1.22
tags: added: cts
Changed in juju-core:
milestone: 1.22-alpha1 → 1.23
Curtis Hovey (sinzui) on 2015-02-10
Changed in juju-core:
milestone: 1.23 → none
importance: High → Medium
tags: added: sts
removed: cts
tags: removed: cts-cloud-review sts
Anastasia (anastasia-macmood) wrote :

Re-targeting for Juju 2.x

Changed in juju:
status: New → Triaged
importance: Undecided → Wishlist
Changed in juju-core:
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers