group.of.nepali.translators team mailing list archive

[Dan Streetman <dan.streetman@xxxxxxxxxxxxx>]

After some thought about this, I believe this 'special case' of vlan-
named-bridge interfaces should be a Won't Fix for trusty and xenial.
The 'special case' has been removed in bionic and later, and 'fixing'
this for t/x would only result in later regressions during release
upgrade.

The original issue - juju creating these vlan-named-bridge interface
names - has been fixed, so I believe it's ok to mark this as won't fix
for vlan for all releases; if anyone has manually (or programmatically)
created such special case interface names, they can fix their manual
naming (or fix their script/application).  The special case was a really
bad idea in the first place, anyway.

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

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

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

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

** Changed in: vlan (Ubuntu Trusty)
       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:
  In Progress
Status in juju 2.4 series:
  Fix Released
Status in vlan package in Ubuntu:
  In Progress
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