Find lxdbr0 even when it doesn't have an address. #6905

Merged
merged 1 commit into from Feb 2, 2017

Conversation

Projects
None yet
3 participants
Owner

jameinel commented Feb 2, 2017

When looking on the host machine for how we might want to
configure a container, we actually weren't finding 'lxdbr0'
because it didn't have an address. This changes the
machine.LinkLayerDevicesForSpaces so that it first builds
up devices based on their addresses, and then does a
pass to create the devices based on what they are
connected to.

This properly connects things together for places like
AWS that only have the local bridge.

QA steps

  $ juju bootstrap ?
  $ juju switch controller
  $ juju add-machine lxd:0
  $ juju debug-log ...

Without this patch, you'll see lines like:

machine-0: 11:44:07 DEBUG juju.network.containerizer for container "0/lxd/0", found desired spaces: <none>
machine-0: 11:44:07 DEBUG juju.network.containerizer container "0/lxd/0" not qualified to a space, host machine "0" is using spaces <none>
machine-0: 11:44:07 DEBUG juju.network.containerizer container has no desired spaces, and host has no known spaces, triggering fallback to bridge
machine-0: 11:44:07 DEBUG juju.network.containerizer FindMissingBridgesForContainer("0/lxd/0") spaces "" devices map{"":["ens4"]}
machine-0: 11:44:07 INFO juju.network bridgescript command=/usr/bin/python2 - --interfaces-to-bridge="ens4" --activate --bridge-prefix=br-  --rec

Which indicates it was trying to use the host device (it fails so the later fallback to use lxdbr0 when the one we wanted fails makes it ultimately succeed by accident.)

With this patch, you'll see

machine-0: 13:12:15 DEBUG juju.network.containerizer FindMissingBridgesForContainer("0/lxd/2") spaces "" devices map{"":["ens4","lxdbr0"]}
machine-0: 13:12:15 DEBUG juju.provisioner.lxd using multi-bridge networking for container "0/lxd/2"
machine-0: 13:12:15 DEBUG juju.network.containerizer for container "0/lxd/2", found desired spaces: <none>
machine-0: 13:12:15 DEBUG juju.network.containerizer container "0/lxd/2" not qualified to a space, host machine "0" is using spaces <none>
machine-0: 13:12:15 DEBUG juju.network.containerizer container has no desired spaces, and host has no known spaces, triggering fallback to bridge
machine-0: 13:12:15 DEBUG juju.network.containerizer for container "0/lxd/2", found host devices spaces: map{"":["ens4","lxdbr0"]}
machine-0: 13:12:15 DEBUG juju.network.containerizer for container "0/lxd/2" using host machine "0" bridge devices: "lxdbr0"
machine-0: 13:12:15 DEBUG juju.network.containerizer prepared container "0/lxd/2" network config: [{Name:eth0 MTU:1500 ProviderID: Type:ethernet
:true IsUp:true ParentName:m#0#d#lxdbr0}]

Which means that we correctly identified that 'lxdbr0' should be used (there should be no call to the bridging script.)

Documentation changes

This is fixing containers under the covers, so no doc changes.

Bug reference

This is all part of doing https://bugs.launchpad.net/juju/+bug/1657449 correctly.
It also is a step along the path for https://bugs.launchpad.net/juju/+bug/1656326 because by directly requesting 'lxdbr0' we can remove the code that 'falls back' to lxdbr0.

axw approved these changes Feb 2, 2017

LGTM.

Does this change mean that a device may start out being reported in the unknown space, and then move to a named space later when it gets an address? Is that OK?

@@ -923,59 +923,72 @@ func (m *Machine) LinkLayerDevicesForSpaces(spaces []string) (map[string][]*Link
if err != nil {
@axw

axw Feb 2, 2017

Member

I think the method's doc comment is incorrect now, since devices without addresses are being returned.

Owner

jameinel commented Feb 2, 2017

Ultimately, we'd want to be looking more at L2 connectivity to determine whether a device is in a space or not. As for "moving", its certainly possible for us to bridge at the wrong time because we looked at the wrong time.

However, the current reality is that you should really either always be in "undefined" space (for places where we don't have space support) or always only in defined space (for places where we do), so there shouldn't really be a possibility of moving between them.

Owner

jameinel commented Feb 2, 2017

$$merge$$

Contributor

jujubot commented Feb 2, 2017

Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju

Contributor

jujubot commented Feb 2, 2017

Build failed: Does not match ['fixes-1660877']
build url: http://juju-ci.vapour.ws:8080/job/github-merge-juju/10179

Owner

jameinel commented Feb 2, 2017

$$merge$$
JFDI

Contributor

jujubot commented Feb 2, 2017

Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju

Contributor

jujubot commented Feb 2, 2017

Build failed: Generating tarball failed
build url: http://juju-ci.vapour.ws:8080/job/github-merge-juju/10180

Find lxdbr0 even when it doesn't have an address.
When looking on the host machine for how we might want to
configure a container, we actually weren't finding 'lxdbr0'
because it didn't have an address. This changes the
machine.LinkLayerDevicesForSpaces so that it first builds
up devices based on their addresses, and then does a
pass to create the devices based on what they are
connected to.

This properly connects things together for places like
AWS that only have the local bridge.
Owner

jameinel commented Feb 2, 2017

$$merge$$ (go fmt + squash)

Contributor

jujubot commented Feb 2, 2017

Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju

Contributor

jujubot commented Feb 2, 2017

Build failed: Tests failed
build url: http://juju-ci.vapour.ws:8080/job/github-merge-juju/10181

Owner

jameinel commented Feb 2, 2017

$$merge$$ (test failed with a nil-pointer exception in a mongo.sync call)

Contributor

jujubot commented Feb 2, 2017

Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju

@jujubot jujubot merged commit ec0470a into juju:2.1 Feb 2, 2017

@jameinel jameinel deleted the jameinel:2.1-find-bridges-correctly branch Apr 22, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment