group.of.nepali.translators team mailing list archive

[Dan Streetman <dan.streetman@xxxxxxxxxxxxx>]

hi, here are some clarifications on this bug:

> https://salsa.debian.org/debian/vlan/blob/debian/debian/network/if-pre-up.d/vlan#L21
> https://salsa.debian.org/debian/vlan/commit/7517228145310a29b7cb7f4bddccb1b70df347eb

these have nothing to do with this bug.  those changes are in case
sections that don't match the naming of your interface - yours starts
with "br-*" while those changes are in sections that only match actual
interface naming (i.e., not starting with "br-").

Additionally, I'm pretty sure that check was incorrectly written and has
never worked the way they thought it was working - i.e. it should check
for -n "$IF_BRIDGE_PORTS", but it doesn't, it checks for -z, so it
*won't* exit when called for a device that includes a 'bridge_ports'
param - it will exit for a normally-named interface with vlan extension
*without* vlan-raw-device or bridge_ports defined, which may be why it
was removed from ubuntu long ago (looks like it was re-introduced to
ubuntu in cosmic, so i should probably go and fix that too).

>
https://git.launchpad.net/ubuntu/+source/vlan/commit/?id=4c88eab61549ec4c6c8ed65e9610fca712ed98f4

getting closer with this one, but not quite there yet :)

this is the change that introduces this regression:

https://git.launchpad.net/ubuntu/+source/vlan/commit/?h=applied/ubuntu
/bionic-devel&id=117d183fa16e2d5e43da4cfe03e7e8685d27c6d1

yep it was me, sorry.

I want to say that I absolutely *HATE* the debian ifupdown api that
allows this kind of 'automagic' vlan creation just by appending ".NNN"
to an interface's name.  Is it *really* so hard to add a simple "vlan-
raw-device" param to the config?  The 'automagic'-ness of it makes
things *much* harder - especially when there are special cases like
this, a bridge on top of a vlan.

In any case, we can fix this regression by special-casing any configured
interface that includes a "bridge_ports" param, which (basically) should
get us back to how things worked before.

However, I personally think it's super, super confusing for juju to name
a bridge device with vlan suffix, and I highly support the juju patch
from comment 3 that changes the '.' to '-' (in addition to fixing this
regression in vlan).


** Changed in: vlan (Ubuntu)
     Assignee: (unassigned) => Dan Streetman (ddstreet)

** Changed in: vlan (Ubuntu)
   Importance: Undecided => Medium

** Changed in: vlan (Ubuntu)
       Status: New => In Progress

** Also affects: vlan (Ubuntu Xenial)
   Importance: Undecided
       Status: New

** Also affects: vlan (Ubuntu Cosmic)
   Importance: Undecided
       Status: New

** Also affects: vlan (Ubuntu Trusty)
   Importance: Undecided
       Status: New

** Also affects: vlan (Ubuntu Disco)
   Importance: Medium
     Assignee: Dan Streetman (ddstreet)
       Status: In Progress

** Also affects: vlan (Ubuntu Bionic)
   Importance: Undecided
       Status: New

-- 
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:
  New
Status in vlan source package in Xenial:
  New
Status in vlan source package in Bionic:
  New
Status in vlan source package in Cosmic:
  New
Status in vlan source package in Disco:
  In Progress

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