On it! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1664844
Title: No distinction between link-up and link-down interfaces Status in MAAS: Triaged Status in netplan: In Progress Status in netplan.io package in Ubuntu: In Progress Status in systemd package in Ubuntu: Fix Released Status in netplan.io source package in Xenial: Won't Fix Status in systemd source package in Xenial: Won't Fix Status in netplan.io source package in Zesty: Won't Fix Status in systemd source package in Zesty: Won't Fix Status in netplan.io source package in Artful: Won't Fix Status in netplan.io source package in Focal: New Status in systemd source package in Focal: Fix Committed Status in netplan.io source package in Groovy: New Status in systemd source package in Groovy: Fix Committed Status in netplan.io source package in Hirsute: New Status in systemd source package in Hirsute: Fix Committed Bug description: [Impact] Since very long, we had a feature request in netplan to determine the activation mode of a given network interface. We got requests to enable marking some interfaces as 'manual', meaning that networkd (or any other backend) would not control its state in any way, requiring the administrator to bring the interface up or down manually. The other request was to mark a interface as 'off', that is: forcing the network interface to always be down until the configuration option isn't changed. This was mainly requested for the networkd backend and requires the new feature of specifying ActivationPolicy= for interfaces, alongside the required netplan changes. This feature is present in systemd 248 - for netplan supported stable series we have decided to cherry-pick and backport this feature on top of current systemd. The networkd feature basically adds the following 5 ActivationPolicy modes: always-down, down, manual, up, always-up. For netplan purposes we only use 'always-down' and 'manual'. The netplan feature, hopefully landing as part of 0.103, is called 'activation-mode' and supports two values: 'manual' and 'off'. [Test Case] For the systemd part: * Bring up a VM test environment with either a dummy interface or an interface that can be safely manipulated. * Upgrade systemd to the -proposed version * For the target interface, create/modify the networkd configuration to include the ActivationPolicy= setting in [Link], for instance: [Match] Name=dummy0 [Network] Address=192.168.10.30/24 Gateway=192.168.10.1 [Link] ActivationPolicy=manual * Try all 5 combinations of ActivationPolicy values: always-down, down, manual, up, always-up - doing `sudo networkctl reload` everytime and checking if the interface behaves as expected. [Where problems could occur] The patchset modifies quite a lot of code in the networkd link handling code paths, so regressions could appear in how networkd manages links - maybe by suddenly certain interfaces not getting brought up as they were before. By code inspection, the implementation defaults to ACTIVATION_POLICY_UP as the default, equivalent to the current behavior, so this risk is small. --- [Original Description] [Old Impact] Users need to write valid configuration, especially for new features that are approved by not yet implemented, such as marking a link "optional". [Old Test case] Write a netplan configuration: network: version: 2 renderer: networkd ethernets: eth0: optional: yes dhcp4: yes And run 'netplan apply'. Netplan should write configuration for the link and not error out with a syntax error. [Old Regression potential] This has a minimal potential for regression: the new keyword was added to be supported already by consumers of netplan (users, cloud-init) so that they could start writing config with the new key and that configuration to be seen as valid by netplan before the backend is implemented. There is no functional change besides allowing for the value to exist in a netplan configuation. --- If I define an interface in netplan (even one which has no DHCP type and no addresses), it's not possible to determine if its adminStatus should be enabled (link up) or disabled (link down). I can completely exclude an interface from the netplan configuration, but I think that implies that not only its adminStatus is "disabled" by default, but also netplan will not be able to do anything "nice" for the interface, such as rename it to what the user specified in MAAS. If I include the interface but don't specify any addresses or DHCP, it isn't clear if it will be link up (my current assumption) or link down. There should be a way to allow an interface to be recognized by netplan (and even partially configured, waiting for the user to run something like 'ifup <interface>' on a manual but not auto-started interface in ifupdown), but marked administratively disabled. (adminStatus down) To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1664844/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
