Ubuntu Wiki

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

• Launchpad Entry: foundations-aa-migrating-to-netplan

• Packages affected: cloud-init maas netcfg nplan ifupdown juju systemd

Summary

Migrate default installs from ifupdown to netplan as a preferred method of describing network configuration for users, and leaving the implementation details to netplan itself. Make sure people can easily describe complex network configurations without worrying about the syntax required by the software that will implement the configuration.

Deprecate ifupdown in Ubuntu for the 17.10 release. Deliver a unified network stack of netplan and networkd/network-manager across all 17.10 images in preparation for the 18.04 LTS.

This will make it easier to have a consistent experience across all systems when it comes to configuring network devices; as well as how to do the configuration when dealing with multiple systems at once via MaaS or as provisioned in clouds using cloud-init.

Release Note

Ubuntu 17.10 introduces a new default configuration method for network devices, using netplan instead of ifupdown. Configuration is now written as YAML files to /etc/netplan instead of in /etc/network/interfaces. See Netplan for more information about how to configure your network devices.

Rationale

Netplan has been implemented to support simple, declarative representation of complex network configurations, as well as address some current limitations of ifupdown. Netplan provides a simple and elegant yaml configuration format with support for multiple backend providers.

Some of the shortcomings of ifupdown covered by netplan:

• ifupdown cannot represent all configs with a purely declarative syntax; therefore we can not parse the config
  • all netplan config is purely declarative.
• ifupdown can only represent interfaces by name, so it is not portable across devices
  • netplan uses matching by name, MAC address, driver, etc.
• race conditions in complex configs
  • netplan has the context of hierarchy in the definition of the interfaces, such that this information is carried over to the renderer used and applied in the right ordering.

Given increasing demand for complex networking scenarios (large cloud uses often require complex layering of different features, such as bridges over bonds over VLANs, etc.), it has shown to be important to improve the ease of representing the network config.

Use Cases

• ACME wants to set up a new hyper-speed cloud for their clients, and need to configure VLANs on multiple bonded devices, bridged to the various networks. They can use netplan to easily define the network, and let netplan generate and apply the configuration to systemd-networkd or NetworkManager without having to worry about different syntaxes.

Implementation

Summary

This is implemented by switching to using netplan configuration by default, stop seeding ifupdown; initial feedback.

Early on, we switch to using netplan by default; this is a rather straight-forward stop of stopping to seed ifupdown. This can be done as soon as this spec is agreed upon.

Some pieces will require code changes: debian-installer (netcfg) will need to be writing the new config format; changing netcfg is a critical, but relatively simple step (netcfg should write both configs to start with).

Make a go/no-go decision on whether netplan is appropriately doing its job by the Artful Final Beta; September 28th 2017.

UI Changes

Not applicable.

Code Changes

debian-installer / netcfg

Netcfg needs to write network V2 YAML as well as e/n/i configuration.

Migration

There is a netplan ifupdown-migrate command that exists that may be used by system administrators to convert simple ifupdown configuration to netplan. Typical upgrade scenarios would automatically keep ifupdown installed; and we will rely on users to do the migration themselves.

Test/Demo Plan

• Testing should be ongoing to make sure there are no regressions. Expect feedback at any step of the migration. This is achieved with autopkgtests in netplan: all new features should include integration tests that exercise them, and can identify regressions caused by other changes or changes to the underlying renderer tools.
• Spin up instances of all supported clouds to make sure they work in a world without ifupdown, using netplan instead.
• Validate that on installs of server and with "alternate" desktop images, netplan config is written to the installed system by debian-installer.
• Test common network designs in place (install a system, configure netplan to the desired design, reboot, and validate that the configuration comes up as expected):
  • Bridged devices: have the system come up on two separate interfaces on separate networks, bridge them together and apply the right IP addresses and routing.
  • Bonded devices: bring up system with two bonded devices, ensure that both are correctly added to the virtual bond, system boots correctly and without delay.
  • DHCP interface: a system can be brought up and installed with DHCP from d-i and will correctly come up and use the configuration supplied from the installer.
  • Static IP: a system can be brought up and installed with a static IP address from d-i and will correctly come up and use the configuration supplied from the installer.
  • MaaS installs: system can be brought up with a configuration from MaaS and the configuration supplied will be used by the system as boot.

Outstanding Issues

Systemd bugs (to be identified precisely).

BoF agenda and discussion

BoF Notes

Signoff

CategorySpec