No documented way to pass in bond or bridge paramters

Bug #1664702 reported by Mike Pontillo on 2017-02-14
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
netplan
Medium
Mathieu Trudel-Lapierre
nplan (Ubuntu)
Undecided
Unassigned
Xenial
Undecided
Unassigned

Bug Description

[Impact]
Documentation is important for users to know how to write the required configuration file for bond or bridge device parameters.

[Test case]
- Run nplan integration tests on the release
- Validate that netplan generate && netplan apply alone, without config, behave as expected (no result)
- Validate that netplan generate && netplan apply with minimal config writes /run/NetworkManager/conf.d/10-globally-managed-devices.conf
- Validate that netplan generate && netplan apply works with any existing configuation.
- Validate that documentation shipped with netplan includes information about the allowed parameters for bond and bridge devices (see /usr/share/doc/netplan/netplan.html)

[Regression potential]
Any failure to work with existing configuration should be considered a regression. Any new failure of the test suite would be a regression.

---

According to the current documentation[1], there is no way to set bond or bridge parameters. This is a requirement for the MAAS use case.

MAAS passes these parameters in the v1 YAML the same way as they are represented in /etc/network/interfaces[2], inside a 'params' dictionary. This allows interface type specific settings such as spanning-tree and bonding modes to be specified, such as:

br0:
  params:
    bridge_stp: on
...
bond0:
  params:
    bond-mode: 4

(Note the quirk there with '-' being used for the bond and '_' for the bridge; this is due to to an inconsistency regarding the /e/n/i syntax.)

I'm tentatively thinking of passing them in the same way, to prevent information loss. But perhaps this could be standardized; a 'params' dictionary could be used for generic OS or renderer-specific settings where there is no guarantee of support, but netplan could standardize commonly-used settings and present them in an "official" after they each parameter has been fully specified.

[1]:
https://git.launchpad.net/netplan/tree/doc/netplan.md

[2]:
https://wiki.debian.org/NetworkConfiguration

Changed in netplan:
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
Changed in netplan:
status: In Progress → Fix Committed

This landed in nplan 0.19:

nplan (0.19) zesty; urgency=medium

  * Add support for unordered definition of network devices: you can now
    specify a virtual devices before their member devices. (LP: #1670495)
  * Allow setting up the STP state for a bridge. (LP: #1665088)
  * Document bond/bridge parameters support. (LP: #1664702)

Changed in netplan:
status: Fix Committed → Fix Released
description: updated

Hello Mike, or anyone else affected,

Accepted nplan into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nplan/0.21~16.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in nplan (Ubuntu Xenial):
status: New → Fix Committed
tags: added: verification-needed

Should have been marked Fix Released for Zesty too.

Changed in nplan (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers