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 _______________________________________________ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
