netplan:lp1804861

Last commit made on 2018-12-07
Get this branch:
git clone -b lp1804861 https://git.launchpad.net/netplan

Branch merges

Branch information

Name:
lp1804861
Repository:
lp:netplan

Recent commits

9c00fea... by Mathieu Trudel-Lapierre on 2018-12-07

Merge branch 'master' into lp1804861

4146145... by Shashank Ram <email address hidden> on 2018-12-04

Add support to override networkd UseMTU setting

Currently, there is no way to override networkd's
UseMTU flag via Netplan. This is useful to have
as a dhcp-override option similar to the other
dhcp-override options.
If the 'use-mtu' key is set to false in the netplan
config file, then set 'UseMTU' as false in networkd's
config.

Signed-off-by: Shashank Ram <email address hidden>

c1aa376... by Mathieu Trudel-Lapierre on 2018-12-05

networkd: Workaround matching interaction bug with networkd

Some installation services generate netplan configuration that is a little
verbose, including default values for fields that are really optional.

These would potentially be fine, if misguided, if networkd was to do a better
job at matching -- however, it can't really do so, since it's also not given
additional matching criteria.

We're not given that matching criteria either, but while things get sorted
out in the various installation services, attempt to workaround this
scenario by defining the match for this particular case (bonds using the
MAC address of a member phy, defined as such in the config) to try
and catch only the ethernet devices. As those don't have DEVTYPE, do
some further fuzzy matching by excluding vlans, bridges and bonds.

To be clear: IT IS NOT RECOMMENDED to rely on this behavior. If you want
to match on something, make sure to be clear as to what the matching
criteria are; and if a field is optional, do not specify it unless you
REALLY know what you're doing.

Bug-Ubuntu: https://bugs.launchpad.net/netplan/+bug/1804861

Signed-off-by: Mathieu Trudel-Lapierre <email address hidden>

1395869... by Julien Fortin <email address hidden> on 2018-11-17

Generate output files in dependency order

Today, to generate the various output files, netplan iterates through it's
netdef hash-table without considering any interfaces dependencies. This may
cause issues for some backend that are "dependency sensitive", like ifupdown2.

Considering the following example file from the netplan repository:

$ cat /etc/netplan/bonding_router.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: no
    enp2s0:
      dhcp4: no
    enp3s0:
      dhcp4: no
      optional: true
    enp4s0:
      dhcp4: no
      optional: true
    enp5s0:
      dhcp4: no
      optional: true
    enp6s0:
      dhcp4: no
      optional: true
  bonds:
    bond-lan:
      interfaces: [enp2s0, enp3s0]
      addresses: [192.168.93.2/24]
      parameters:
        mode: 802.3ad
        mii-monitor-interval: 1
    bond-wan:
      interfaces: [enp1s0, enp4s0]
      addresses: [192.168.1.252/24]
      gateway4: 192.168.1.1
      nameservers:
        search: [local]
        addresses: [8.8.8.8, 8.8.4.4]
      parameters:
        mode: active-backup
        mii-monitor-interval: 1
        gratuitious-arp: 5
    bond-conntrack:
      interfaces: [enp5s0, enp6s0]
      addresses: [192.168.254.2/24]
      parameters:
        mode: balance-rr
        mii-monitor-interval: 1
$

Please review the following netplan output, to make my point I took the liberty
to add a printf statement in the nd_iterator function (from generate.c). When
running "netplan generate" we can see that there isn't any specific ordering:

$ netplan generate
nd_iterator generate interface: enp4s0
nd_iterator generate interface: bond-wan
nd_iterator generate interface: enp5s0
nd_iterator generate interface: enp6s0
nd_iterator generate interface: enp1s0
nd_iterator generate interface: bond-lan
nd_iterator generate interface: enp2s0
nd_iterator generate interface: bond-conntrack
nd_iterator generate interface: enp3s0
$

Introducing ifupdown2 a network manager using the "ifupdown" syntax. It creates
a "stanza" for each interface. We store the final configuration in /etc/network/interfaces.
An example bond config looks like this:

auto bond42
iface bond42
 bond-slaves swp42 swp84
 bond-mode 802.3ad
 address 42.42.42.42/32

Unlike other network manager like networkd, you can see here that the bond
interface is dependent on it's slaves.
The current netplan implemention is great but we believe that some of it's
limitation (like the dependency ordering) should be addressed so more backend
could be added. Today when the ifupdown2 backend is called with the "netdef"
bond42, the bond doesn't have any knowledge of it's slaves. Thus making it
hard for the backend to generate the proper stanzas.

If the output file generation would be moved to a dependency-ordered
generation, ifupdown2 backend would store the master-slaves relationships
internally thus avoiding iterating through the whole hash-table for every
interfaces, and output the correct stanza for each interface.

In the following logs I used the same printf statement as before to output the
new behavior of "nd_iterator_list" to show that interfaces are generated in a
dependency order fashion:

$ netplan/generate
nd_iterator_list generate interface: enp1s0
nd_iterator_list generate interface: enp2s0
nd_iterator_list generate interface: enp3s0
nd_iterator_list generate interface: enp4s0
nd_iterator_list generate interface: enp5s0
nd_iterator_list generate interface: enp6s0
nd_iterator_list generate interface: bond-lan
nd_iterator_list generate interface: bond-wan
nd_iterator_list generate interface: bond-conntrack
$

Signed-off-by: Julien Fortin <email address hidden>

ae4bf6f... by Mathieu Trudel-Lapierre on 2018-11-29

generator tests: remove shebangs, clean up importing

44f5a82... by Mathieu Trudel-Lapierre on 2018-11-28

tests: refactor tests to avoid a single huge generate.py

f021b63... by Mathieu Trudel-Lapierre on 2018-11-29

TODO: investigate replacement for nosetests

44df936... by Michael Hudson-Doyle on 2018-11-25

changelog

ea41423... by Michael Hudson-Doyle on 2018-11-25

Do not assume /etc/network exists in postinst, as netbase 5.5 no longer creates it

865726f... by Michael Hudson-Doyle on 2018-11-25

netplan/cli/commands/ip.py: fix a flake.