← Back to team overview

group.of.nepali.translators team mailing list archive

[Bug 1804018] Re: Autogenerated interface name prevents creating a bridge over a VLAN

 

Marking the main task as "wontfix" too, as disco was.

** Changed in: vlan (Ubuntu)
       Status: In Progress => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1804018

Title:
  Autogenerated interface name prevents creating a bridge over a VLAN

Status in juju:
  Fix Released
Status in juju 2.4 series:
  Fix Released
Status in vlan package in Ubuntu:
  Won't Fix
Status in vlan source package in Trusty:
  Won't Fix
Status in vlan source package in Xenial:
  Won't Fix
Status in vlan source package in Bionic:
  Won't Fix
Status in vlan source package in Cosmic:
  Won't Fix
Status in vlan source package in Disco:
  Won't Fix

Bug description:
  Hi,

  First of all, thanks for all your work on creating and maintaining
  Juju and the charms ecosystem!

  I believe I have stumbled onto a bug in autogenerating the name for
  the bridge interface when one needs to be created to grant a container
  access to a host's network interface.  This bug is currently blocking
  a MAAS/Juju/OpenStack deployment where traffic is separated into
  VLANs.  I have successfully reproduced it on 2.4.6 and 2.5-beta1
  installations, although I believe that it has been present ever since
  at least 2.2.0, if not maybe earlier.

  Currently the name of the bridge interface is, if possible, generated
  by prepending "br-" to the host interface name; however, this is
  problematic with VLAN interfaces.  If the host interface is called
  e.g. "enp3s0f0.503", this would create a bridge named "br-
  enp3s0f0.503"; however, if there is *also* a bridge on the "enp3s0f0"
  interface (without the VLAN ID), this would cause the Debian/Ubuntu
  ifupdown scripts to consider "br-enp3s0f0.503" to be VLAN 503 on the
  "br-enp3s0f0" interface and, consequently, fail to bring it up
  correctly the next time the node is rebooted.

  Steps to reproduce:

  1. Define a node with an Ethernet interface (let's call it "enp3s0f0")
  and a network space (let's call it "mgmt")

  2. Define a VLAN over that interface (let's call it "enp3s0f0.503")
  and a network space for the VLAN (let's call it "storage")

  3. Deploy a charm on that node so that Juju knows about the enp3s0f0
  interface in the mgmt space and the enp3s0f0.503 interface in the
  storage space

  4. Deploy a charm in a container, specitying `--constraints
  spaces=storage`; this will lead to Juju autogenerating a bridge
  interface and calling it "br-enp3s0f0.503"

  5. Deploy a charm in a container, specifynig `--constraints
  spaces=mgmt`; this will lead to Juju autogenerating another bridge
  interface and calling it "br-enp3s0f0"

  6. Reboot the server, then log into it

  The br-enp3s0f0 bridge may be brought up correctly, but the br-
  enp3s0f0.503 interface, although it will exist, will have been created
  as a VLAN interface, not a bridge interface, and so any attempts to
  add any interfacesd to it will have failed; consequently, the
  container will also have failed to start up.

  A naive fix for newly-bootstrapped environments would be to replace
  any dots with e.g. dashes in the `BridgeNameForDevice()` function in
  the `network/containerizer/bridgepolicy.go` file - this will lead to
  creating the new interface with a name that will not be interpreted as
  a VLAN over an existing interface.  However, I think that a proper fix
  would have to include some sort of migration path for existing
  deployments, e.g. generating both the old and new names and possibly
  migrating network interfaces from the old bridge to the new one.

  Please let me know if there is any more information that I can provide
  for a hopefully speedy resolution of this problem.

  Thanks in advance for your consideration, and keep up the great work!

  Best regards,
  Peter

To manage notifications about this bug go to:
https://bugs.launchpad.net/juju/+bug/1804018/+subscriptions