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.
Ifupdown is still available in the archive, and can be reinstalled by running the command: "sudo apt install ifupdown".
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.
- John provisions a 17.10 system using MaaS; nplan is used automatically to configure the network on the system.
- Mark installs lxd. When starting a guest, netplan correctly handles the network configuration and the guest comes up with the expected network configuration.
- Jill bring up a new system for a deployment using juju; the system comes up with netplan instead of /e/n/i configuration and is reachable from the network.
- William launches an Ubuntu instance in a public cloud. The system comes up and is reachable from the Internet.
Implementation
Summary
Early in the 17.10 cycle, we switch to using netplan by default; this is a rather straightforward change to unseed 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.
Make a go/no-go decision on whether netplan is appropriately doing its job by the Artful Final Beta; September 28th 2017.
This migration plans does not include the removal of ifupdown from the archive. ifupdown will still be available for users who wish to explicitly install it, but would not be automatically installed by default for any Ubuntu deployment.
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
Use @SIG@ to sign-off your team on this Spec.