No distinction between link-up and link-down interfaces

[Mike Pontillo]

[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)

[Ryan Harper (raharper)]

IIUC, we're looking for an equivalent of 'manual' control?

[Mike Pontillo (mpontillo)]

In ifupdown, 'manual' mode does accomplish this, yes. The side effect of this is that systemd does not block booting if the interface hasn't been enabled yet.

So the two relevant configuration knobs are:

(1) Should this interface be brought online at boot time? (default adminStatus)
(2) Should this interface be required to be up (and configured with an IP address) before the machine continues to boot? (lack of this requirement is implied by manual mode plus "auto <ifname>" in ifupdown)

We have seen MAAS bugs where these use cases have been problematic, such as users configuring a "backup bond" which is not (yet) online. (See also #1553617.)

[Mike Pontillo (mpontillo)]

By the way, to add to (2) above, in order to create a link-down DHCP interface which does not block the boot process if DHCP fails, you also need another workaround involving a post-up/pre-down script to launch the DHCP client and release the address, respectively.

[Ryan Harper (raharper)]

On Wed, Feb 15, 2017 at 12:16 PM, Mike Pontillo <<email address hidden>
> wrote:

> By the way, to add to (2) above, in order to create a link-down DHCP
> interface which does not block the boot process if DHCP fails, you also
> need another workaround involving a post-up/pre-down script to launch
> the DHCP client and release the address, respectively.
>

That doesn't seem right; either you want/need the interface to dhcp
(mode=auto)
and then of course you block the boot waiting on DHCP and mark that it
failed
Or it's manual, in which case it;s not blocking boot as it won't be
required "up"
to continue.

>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1664844
>
> Title:
> No distinction between link-up and link-down interfaces
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/netplan/+bug/1664844/+subscriptions
>

[Mike Pontillo (mpontillo)]

I respectfully disagree. Think of deploying a simple router, such as a home NAT gateway. You would likely want wan0 to be in a mode like I described, "link-up interface with DHCP enabled, but don't block boot if you can't DHCP".

 - If wan0 is not link up, I wouldn't want that to block boot. Maybe my ISP is having trouble. Maybe the dog chewed through the cable. I don't know. But I don't to block the boot process (and thus the other functions of the router) because of it. If I block boot, I can't even SSH into the box to figure out what went wrong.

 - If I can't get a DHCP address, that's a problem, but I still don't want to block the boot process. Hopefully my ISP's problem. But I don't want it to block boot. I want the normal DHCP client behavior of exponential-backoff-and-retry until it works. I want the router to be up and running, and properly sending "destination host unreachable" ICMP messages back to clients, not stuck waiting for systemd to confirm what I already know.

[Ryan Harper (raharper)]

On Wed, Feb 15, 2017 at 12:51 PM, Mike Pontillo <<email address hidden>
> wrote:

> I respectfully disagree. Think of deploying a simple router, such as a
> home NAT gateway. You would likely want wan0 to be in a mode like I
> described, "link-up interface with DHCP enabled, but don't block boot if
> you can't DHCP".
>

I certainly agree that there's a need for dynamic configuration of
interfaces.
Networkd doesn't currently provide a complete solution here. And it
certainly
does not provide any link-state monitoring either; but we didn't have one
in
ifupdown either; collection of additional hooks/scripts/tools providing
this function not-with-standing.

I don't think it's clear that not blocking or blocking is the right or
expected
behavior; it's certainly possible that not getting an IP via DHCP might be
equivalent to not booting if that's the only ingress to the box remotely.

> - If I can't get a DHCP address, that's a problem, but I still don't
> want to block the boot process. Hopefully my ISP's problem. But I don't
> want it to block boot. I want the normal DHCP client behavior of
> exponential-backoff-and-retry until it works. I want the router to be up
> and running, and properly sending "destination host unreachable" ICMP
> messages back to clients, not stuck waiting for systemd to confirm what
> I already know.
>

There's clearly a need for this feature, but I don't believe we want to
replicate
a collection of hooks/scripts to deliver this but rather examine what might
be
needed to deliver netlink monitoring/policy application as a first-class
feature.

I briefly looked at https://en.opensuse.org/Portal:Wicked which has a nanny
daemon listening to netlink and the network daemon to handle hotplug events
but can be extended to listen to link status and build actions based on
information.

>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1664844
>
> Title:
> No distinction between link-up and link-down interfaces
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/netplan/+bug/1664844/+subscriptions
>

[Mathieu Trudel-Lapierre (cyphermox)]

Sounds to me like before we can implement something like this, we'd need a way to specify this to the renderer themselves. There will need bugs opened for NetworkManager and networkd to understand "administratively down" states -- ie. we configured this already but we want to keep the device down for now.

Also, as far as I know, systemd/networkd will follow their own rules, which likely currently enforce that interfaces defined as DHCP will attempt configuration even if there is no carrier. This should be tested carefully, and a bug opened if it's indeed an issue. We'll focus on just adminsitrative status for the bug report here.

[Mike Pontillo (mpontillo)]

This is a gray area but I want to say it impacts MAAS -- currently, we represent "link down" by leaving the interface out of the YAML. This is less than ideal.

If this gets fixed we will need to generate a cleaner Netplan YAML in MAAS.

[Steve Langasek (vorlon)]

> - If wan0 is not link up, I wouldn't want that to block
> boot. Maybe my ISP is having trouble. Maybe the dog chewed
> through the cable. I don't know. But I don't to block the
> boot process (and thus the other functions of the router)
> because of it. If I block boot, I can't even SSH into the
> box to figure out what went wrong.

I think this concern is based on an outdated concept of the boot process. Under systemd (which is the only init system for which netplan will be enabled), there is a distinction between 'network' and 'network-online' and only a small number of services will require 'network-online'. ssh is absolutely not one of them.

I think you're still describing a valid bug, in that it is likely useful to distinguish between required and optional interfaces for network-online. But the impact is much less than this.

[Mike Pontillo (mpontillo)]

This bug was observed with a backport of Netplan running on Xenial with systemd.

But if the systemd configuration files for each service will handle this by not blocking boot in the vast majority of cases, I'm happy with that, too.

[Mike Pontillo (mpontillo)]

Well, to clarify, I guess I'm not 100% happy with that. ;-)

What you describe will work for the majority of server and cloud use cases. But installing Ubuntu on a router (or L3 switch) will be problematic if nothing happens when links go up or down. Actions need to be taken, such as adding or removing routes, so that the kernel doesn't attempt to route traffic to link-down interfaces.

That is, with a standard ifupdown configuration, I observe that when an interface becomes link-down (assuming it is administratively up per ifupdown) the IP addresses remain configured, the local routes remain in place, and any routes via the interface remain in the kernel. Arguably this is incorrect behavior, and I don't know if networkd handles this in some different way. (If I remember correctly, it behaved similarly to ifupdown, but correct me if I'm wrong.)

[Steve Langasek (vorlon)]

On Thu, May 25, 2017 at 04:00:16AM -0000, Mike Pontillo wrote:
> Well, to clarify, I guess I'm not 100% happy with that. ;-)

Nor should you be! As I said, this is a valid bug.

> What you describe will work for the majority of server and cloud use
> cases. But installing Ubuntu on a router (or L3 switch) will be
> problematic if nothing happens when links go up or down. Actions need to
> be taken, such as adding or removing routes, so that the kernel doesn't
> attempt to route traffic to link-down interfaces.

Of course, but that is not a function of the netplan yaml declaration; it's
a function of the network config renderer. ifupdown has *no* policy daemon
for handling link-up/link-down events, therefore with ifupdown you don't get
any sensible handling. networkd and NetworkManager should both handle
link-down events correctly. If you find that networkd is *not* handling a
link-down event by removing the routes, please file a bug on systemd for
this and reference it here so we can prioritize resolving it.

The original bug report here that is relevant to netplan is not about
handling transitions between link-up/link-down state, it's about being able
to provide configuration for a network interface with the intent that either
a) this interface will not be automatically brought up, or b) this interface
will not be considered towards network-online status.

On Thu, May 25, 2017 at 03:54:17AM -0000, Mike Pontillo wrote:
> This bug was observed with a backport of Netplan running on Xenial with
> systemd.

If you specifically observed that sshd was not running on a system that had
at least one up interface, that is not the designed behavior and I don't see
any way that this would be a result of a netplan or networkd bug. Please
report a bug on systemd if this is reproducible.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Dimitri John Ledkov (xnox)]

Just to clarify, it's not ever possible to /block/ boot with systemd. Even if all networking is required to complete a boot, but all of them fail, the system will come in "degraded" state. But as much as possible, will be configured.

What one can affect is boot ordering, and what is required to reach certain targets quicker. For example, it sounds like for the systemd-networkd-wait-online.service you may want to extend --ignore= argument with the interfaces that are "semi-managed". They are under networkd control, but one does not care about them during boot.

[Mathieu Trudel-Lapierre (cyphermox)]

I think we're conflating two different issues here; marking a device as "optional" and not required for boot is different than specifying configuration for it, but expecting a backend to leave the interface down.

I'm adding "optional" as a valid config for now so we can start generating valid config, even if that won't be doing much until we have an implementation ready.

[Steve Langasek (vorlon)]

Agreed, these are two separate features, both of which we should support - though optional is the higher priority one, which has bubbled up elsewhere in addition, and having 'optional' is likely a usable workaround for Mike's use case.

[Mathieu Trudel-Lapierre (cyphermox)]

I'll let him comment, but I don't think it is. 'optional' doesn't mean "please know about this config but also don't bring up the interface".

nplan 0.30 is in artful unapproved now, it adds the 'optional' key as something valid for config files.

[Łukasz Zemczak (sil2100)]

Can we get the description follow https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template ? Thank you!

[Łukasz Zemczak (sil2100)]

Hello Mike, or anyone else affected,

Accepted nplan into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nplan/0.32~17.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-zesty to verification-done-zesty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-zesty. 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!

[Łukasz Zemczak (sil2100)]

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.32~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-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. 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!

[Mathieu Trudel-Lapierre (cyphermox)]

nplan 0.32~16.04.2 fails to build because I mismerged 0.32 and broke the code skipping the test_routes_v6 test in the NetworkManager case. Therefore, it can't possibly pass SRU verification.

[Brian Murray (brian-murray)]

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.32~16.04.2 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-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. 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!

[Mathieu Trudel-Lapierre (cyphermox)]

Autopktests still failing for xenial; the test is still not being skipped (we know it won't work on Xenial due to the version of NM shipped there). Marking verification-failed-xenial.

[Łukasz Zemczak (sil2100)]

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.32~16.04.3 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-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. 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!

[Mathieu Trudel-Lapierre (cyphermox)]

verification-done for xenial 0.32~16.04.3, and zesty 0.32~17.04.1:

I verified that the 'optional' keyword is correctly recognized and accepted as valid syntax by netplan.

[TomaszChmielewski (mangoo-wpkg)]

I still see the issue on Ubuntu 17.10.

Using USB wifi device.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Launchpad Janitor (janitor)]

This bug was fixed in the package nplan - 0.32~16.04.3

---------------
nplan (0.32~16.04.3) xenial; urgency=medium

  * tests/integration.py: Really fix skipping test_routes_v6 for the NM
    backend.

nplan (0.32~16.04.2) xenial; urgency=medium

  * tests/integration.py: Fix test_routes_v6 that I clobbered when I re-applied
    the skip rules for 16.04 after merging in 0.32.

nplan (0.32~16.04.1) xenial; urgency=medium

  * Backport netplan 0.32 to 16.04. (LP: #1713142)
  * debian/control: Depend on systemd (>= 229-4ubuntu20) for the PrimarySlave
    feature backported in that revision.
  * tests/integration.py: Skip tests that are still not yet supported in xenial

nplan (0.32) bionic; urgency=medium

  * src/nm.c: better handle the UUID generation; the order of iterating
    through interaces may affect things here. Also make sure the tests catch
    a null UUID.

nplan (0.31) bionic; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * src/nm.c: generate a UUID for a connection only as needed; when we're
    dealing with NM VLANs. (LP: #1712921)
  * debian/tests/autostart: Make the autostart test more verbose and avoid
    failing right from the start when systemd-networkd is disabled.
    (LP: #1699371)
  * tests/integration.py: bump the NetworkManager timeout for settling to
    120 seconds, autopkgtest infrastructure tends to be a little slow for the
    network device configuration to be applied and noticed by NM.
    (LP: #1699371)

  [ Dimitri John Ledkov ]
  * Reload udevd to invalidate configuration cache of .rules/.link files
    as generate step may have changed them. LP: #1669564

  [ Dan Streetman ]
  * Add another interface driver exception to netplan replug to prevent unbind
    of the Xen VIF interfaces. (LP: #1729573)

nplan (0.30) artful; urgency=medium

  * Add an "optional" syntax node for now to all devices. This is unimplemented
    for now, but intended to allow users to mark some devices as optional: to
    make sure they do not delay boot when configured. (LP: #1664844)

nplan (0.29) artful; urgency=medium

  * Fix autopkgtests in a world where /run/NetworkManager/conf.d already
    exists. nplan is enabled by default, so it might well have the directory
    already created on the filesystem.

nplan (0.28) artful; urgency=medium

  * Revert 56cd3eec which disabled IPv6 Router Advertisements by default. It
    broke default network config in LXD and was contrary to the defaults used
    by the kernel. Reopens LP: 1655440. (LP: #1717404)
  * Add "accept-ra:" key for all device types; this will default to OFF but
    allow users to disable processing Router Advertisements when required by
    their network setup. (LP: #1655440)

nplan (0.27) artful; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * Fix crash in systemd generator if called by an user on the command-line
  * coverage: fix exclusions to properly not cover our "never reached defaults"

  [ Dimitri John Ledkov ]
  * tests/integration.py: In teardown, stop systemd-networkd.socket.
  * src/networkd.c: Set UseMTU=true by default, whenever DHCP is in use.
    (LP: #1717471)
  * tests/integration.py: fix resolved detection.

nplan (0.26) artful; urgency=medium

 ...

[Chris Halse Rogers (raof)]

The verification of the Stable Release Update for nplan has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package nplan - 0.32~17.04.1

---------------
nplan (0.32~17.04.1) zesty; urgency=medium

  * Backport 0.32 to 17.04. (LP: #1713142)

nplan (0.32) bionic; urgency=medium

  * src/nm.c: better handle the UUID generation; the order of iterating
    through interaces may affect things here. Also make sure the tests catch
    a null UUID.

nplan (0.31) bionic; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * src/nm.c: generate a UUID for a connection only as needed; when we're
    dealing with NM VLANs. (LP: #1712921)
  * debian/tests/autostart: Make the autostart test more verbose and avoid
    failing right from the start when systemd-networkd is disabled.
    (LP: #1699371)
  * tests/integration.py: bump the NetworkManager timeout for settling to
    120 seconds, autopkgtest infrastructure tends to be a little slow for the
    network device configuration to be applied and noticed by NM.
    (LP: #1699371)

  [ Dimitri John Ledkov ]
  * Reload udevd to invalidate configuration cache of .rules/.link files
    as generate step may have changed them. LP: #1669564

  [ Dan Streetman ]
  * Add another interface driver exception to netplan replug to prevent unbind
    of the Xen VIF interfaces. (LP: #1729573)

nplan (0.30) artful; urgency=medium

  * Add an "optional" syntax node for now to all devices. This is unimplemented
    for now, but intended to allow users to mark some devices as optional: to
    make sure they do not delay boot when configured. (LP: #1664844)

nplan (0.29) artful; urgency=medium

  * Fix autopkgtests in a world where /run/NetworkManager/conf.d already
    exists. nplan is enabled by default, so it might well have the directory
    already created on the filesystem.

nplan (0.28) artful; urgency=medium

  * Revert 56cd3eec which disabled IPv6 Router Advertisements by default. It
    broke default network config in LXD and was contrary to the defaults used
    by the kernel. Reopens LP: 1655440. (LP: #1717404)
  * Add "accept-ra:" key for all device types; this will default to OFF but
    allow users to disable processing Router Advertisements when required by
    their network setup. (LP: #1655440)

nplan (0.27) artful; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * Fix crash in systemd generator if called by an user on the command-line
  * coverage: fix exclusions to properly not cover our "never reached defaults"

  [ Dimitri John Ledkov ]
  * tests/integration.py: In teardown, stop systemd-networkd.socket.
  * src/networkd.c: Set UseMTU=true by default, whenever DHCP is in use.
    (LP: #1717471)
  * tests/integration.py: fix resolved detection.

nplan (0.26) artful; urgency=medium

  * Bonding:
    - Add support for specifying a primary slave. (LP: #1709135)
  * Rebind:
    - Fix brcmfmac harder. Treat any 'brcmfmac' driver as not supporting
      rebind. (LP: #1712224)
  * Autopkgtests:
    - Add allow-stderr. Systemd now bleats about a the networkd socket still
      being around and enabled when we restart the service; but we don't need
      to care since we're /restarting/ the service to load the new config.
    - Fix the autostart package to be more sensible: we don't really care if
 ...

[Chris Halse Rogers (raof)]

Hello Mike, or anyone else affected,

Accepted nplan into artful-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nplan/0.32~17.10.2 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-artful to verification-done-artful. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-artful. In either case, without details of your testing we will not be able to proceed.

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

[Łukasz Zemczak (sil2100)]

Hello Mike, or anyone else affected,

Accepted nplan into artful-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nplan/0.32~17.10.3 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-artful to verification-done-artful. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-artful. In either case, without details of your testing we will not be able to proceed.

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

[Łukasz Zemczak (sil2100)]

Accepted for xenial-proposed. Please test the package and set the verification-done-xenial on success. Thank you!

[Mathieu Trudel-Lapierre (cyphermox)]

Verified nplan 0.32~17.10.3 for artful:
Verified nplan 0.32~16.04.4 for xenial:

nplan behaves as expected when the keyword "optional: yes" is set; device gets ignored by systemd-networkd-wait-online; which will report the correct status based on whether other devices are providing a connection.

[Launchpad Janitor (janitor)]

This bug was fixed in the package nplan - 0.32~17.10.3

---------------
nplan (0.32~17.10.3) artful; urgency=medium

  * Don't silently break Bridge Priority by adding port-priority.

nplan (0.32~17.10.2) artful; urgency=medium

  * Fix syntax for IPv6 addresses in doc. (LP: #1735317)
  * doc: routes are not top-level but per-interface. (LP: #1726695)
  * Implement bridge port-priority parameter. (LP: #1735821)
  * Implement "optional: true" to correctly write systemd network definitions
    with "RequiredForOnline=false", such that these networks do not block boot.
    (LP: #1664844)
  * Various documentation fixes. (LP: #1751814)

 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 02 Mar 2018 16:50:47 -0500

[Launchpad Janitor (janitor)]

This bug was fixed in the package nplan - 0.32~16.04.4

---------------
nplan (0.32~16.04.4) xenial; urgency=medium

  [ Oliver Grawert ]
  * Prevent unbinding ath6kl_sdio, driver does not support it correctly.
    (LP: #1741910)

  [ Mathieu Trudel-Lapierre ]
  * Re-add snap support patch. (LP: #1747714)
  * Fix syntax for IPv6 addresses in doc. (LP: #1735317)
  * doc: routes are not top-level but per-interface. (LP: #1726695)
  * Implement bridge port-priority parameter. (LP: #1735821)
  * Implement "optional: true" to correctly write systemd network definitions
    with "RequiredForOnline=false", such that these networks do not block boot.
    (LP: #1664844)
  * Various documentation fixes. (LP: #1751814)

 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 02 Mar 2018 17:02:03 -0500

[Mathieu Trudel-Lapierre (cyphermox)]

Repurposing this bug now to track the feature work for a specific activation mode option in netplan to keep interfaces administratively down (or manually configured)

[Mattias Thidell (mattias.thidell.coloreel)]

Accidentally pressed "Fix Release" for (Ubuntu Xenail)
Didn't even know I had permission to change status to "Fix Release"

Please revert my changes to "In Progress"

[Nico Orrù (nigu-orru)]

I need this too. How do I vote?

[Mark Shuttleworth (sabdfl)]

Is there an updated target release for the ability to describe configuration for an interface (such as name) but leave the interface down at boot?

[Lukas Märdian (slyon)]

We are actively working on it for the current 20.10 cycle.

But it needs some changes in systemd-networkd, which are currently blocked due to a discussion upstream: https://github.com/systemd/systemd/pull/15060

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Brian Murray (brian-murray)]

Hello Mike, or anyone else affected,

Accepted systemd into hirsute-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/247.3-3ubuntu3.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, what testing has been performed on the package and change the tag from verification-needed-hirsute to verification-done-hirsute. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-hirsute. In either case, without details of your testing we will not be able to proceed.

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

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Murray (brian-murray)]

Hello Mike, or anyone else affected,

Accepted systemd into groovy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/246.6-1ubuntu1.4 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, what testing has been performed on the package and change the tag from verification-needed-groovy to verification-done-groovy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-groovy. In either case, without details of your testing we will not be able to proceed.

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

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Murray (brian-murray)]

Hello Mike, or anyone else affected,

Accepted systemd into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/245.4-4ubuntu3.7 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, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

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

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Dan Streetman (ddstreet)]

@sil2100 can you verify this bug please

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted systemd (246.6-1ubuntu1.4) for groovy have finished running.
The following regressions have been reported in tests triggered by the package:

casync/2+20190213-1 (s390x)
udisks2/2.9.1-2ubuntu1 (arm64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/groovy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted systemd (247.3-3ubuntu3.1) for hirsute have finished running.
The following regressions have been reported in tests triggered by the package:

systemd/247.3-3ubuntu3.1 (armhf)
udisks2/2.9.2-1ubuntu1 (arm64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/hirsute/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Łukasz Zemczak (sil2100)]

On it!

[Łukasz Zemczak (sil2100)]

On a focal multipass instance:

$ apt-cache policy systemd
systemd:
  Installed: 245.4-4ubuntu3.7
  Candidate: 245.4-4ubuntu3.7
  Version table:
 *** 245.4-4ubuntu3.7 500
        500 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages
        100 /var/lib/dpkg/status

I have tried all 5 combinations of the ActivationPolicy setting for a dummy interface and confirmed that those work as expected.

[Łukasz Zemczak (sil2100)]

Okay, I think I see an issue that I'm investigating right now, this might be a verification-failed actually. We might need to cherry-pick something more than just the selected patchset.

I have observed that if you set ActivationPolicy to a mode that doesn't default to bringing the interface up on boot (like 'manual', 'down' or 'always-down'), systemd will wait indefinitely for the given interface to become online on reboot. This only happens for the SRUs, impish seems to be fine - which means that we might be missing a later change to make sure there is no wait in this case.

[Łukasz Zemczak (sil2100)]

Ok, after discussing with Dan, it seems we'll let this through as-is. Actually it's not entirely clear to me why this works differently with 248.3 on impish. We decided that currently, by design, this is 'expected behavior' and requires explicitly setting RequiredForOnline=no. Dan will propose an upstream patch to change that behavior though.

From the netplan side we'll make sure to do that.

[Łukasz Zemczak (sil2100)]

In the meantime, continuing on with the verification. On a groovy multipass instance:

$ apt-cache policy systemd
systemd:
  Installed: 246.6-1ubuntu1.4
  Candidate: 246.6-1ubuntu1.4
  Version table:
 *** 246.6-1ubuntu1.4 500
        500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages
        100 /var/lib/dpkg/status

I have tried all 5 combinations of the ActivationPolicy setting for a dummy interface and confirmed that those work as expected. Reboot tested with RequiredForOnline=no set manually - all good.

[Łukasz Zemczak (sil2100)]

On a hirsute multipass instance:

$ apt-cache policy systemd
systemd:
  Installed: 247.3-3ubuntu3.1
  Candidate: 247.3-3ubuntu3.1
  Version table:
 *** 247.3-3ubuntu3.1 500
        500 http://archive.ubuntu.com/ubuntu hirsute-proposed/main amd64 Packages
        100 /var/lib/dpkg/status

I have tried all 5 combinations of the ActivationPolicy setting for a dummy interface and confirmed that those work as expected. Same as before, I also did a reboot while making sure RequiredForOnline is set to no and things seem to be working as expected. Verified!

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 247.3-3ubuntu3.1

---------------
systemd (247.3-3ubuntu3.1) hirsute; urgency=medium

  [ Andy Chi ]
  * debian/patches/lp1926547-hwdb-60-keyboard-Update-Dell-Privacy-Local-Mic-Mute-.patch
    - Apply upstream patch to correct key and device mapping.
      (LP: #1926547)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=f360a705d992205e3da511910c859e81390e93c6

  [ Łukasz 'sil2100' Zemczak ]
  * d/p/lp1664844/0001-network-add-ActivationPolicy-configuration-parameter.patch,
    d/p/lp1664844/0002-test-add-ActivationPolicy-unit-tests.patch,
    d/p/lp1664844/0003-save-link-activation-policy-to-state-file-and-displa.patch:
    - add support for configuring the activation policy for an interface
      (LP: #1664844)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ae75627f573f5946169819e4fdfe89290badaf21

  [ Dan Streetman ]
  * d/p/debian/UBUNTU-resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-with.patch,
    d/p/lp1785383-resolved-address-DVE-2018-0001.patch:
    - Use upstream patch for DVE-2018-0001 handling (LP: #1785383)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=6c6e948e4364649a4a803a8f1c9cdd5c70e1f0ab
  * d/p/lp1929849-rfkill-add-some-casts-to-silence-Werror-sign-compare.patch:
    - Fix FTBFS due to kernel header change (LP: #1929849)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=656bfde76b7a2d172d84d4e7905d80e1dfa2b68d

 -- Dan Streetman <email address hidden> Thu, 27 May 2021 11:09:57 -0400

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 246.6-1ubuntu1.4

---------------
systemd (246.6-1ubuntu1.4) groovy; urgency=medium

  [ Andy Chi ]
  * debian/patches/lp1926547-hwdb-60-keyboard-Update-Dell-Privacy-Local-Mic-Mute-.patch
    - Apply upstream patch to correct key and device mapping.
      (LP: #1926547)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=a4c14d1c8370445e315ffa59b0a7ce593a79fbf4

  [ Dan Streetman ]
  * d/p/lp1921696/0001-rfkill-improve-error-logging.patch,
    d/p/lp1921696/0002-rfkill-use-short-writes-and-accept-long-reads.patch:
    Handle rfkill api change in kernel 5.10 (LP: #1921696)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=b683c842c74b5f193555fd79bc76e574a025f5b1
  * d/p/lp1929560-network-move-set-MAC-and-set-nomaster-operations-out.patch:
    Move link mac and master config out of link_up() (LP: #1929560)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=a90963d52a70c0ed1b429b1025b95f8c0fa6e7aa
  * d/p/lp1902891-core-mount-mount-command-may-fail-after-adding-the-c.patch:
    Handle failed mount command (LP: #1902891)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=d83f3bce38e04395c6406c3c45efbc9977ae1138
  * d/p/debian/UBUNTU-resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-with.patch,
    d/p/lp1880258-log-nxdomain-as-debug.patch,
    d/p/lp1785383-resolved-address-DVE-2018-0001.patch:
    - Use upstream patch for DVE-2018-0001 handling (LP: #1785383)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=eb311ad89c5fd570bf3af362d8a2af1b357be3dd

  [ Łukasz 'sil2100' Zemczak ]
  * d/p/lp1664844/0001-network-add-ActivationPolicy-configuration-parameter.patch,
    d/p/lp1664844/0002-test-add-ActivationPolicy-unit-tests.patch,
    d/p/lp1664844/0003-save-link-activation-policy-to-state-file-and-displa.patch:
    - add support for configuring the activation policy for an interface
      (LP: #1664844)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=0b0a9202964b24fb8d9fb4b28bdb22c6aadd25b7

 -- Dan Streetman <email address hidden> Thu, 27 May 2021 11:13:07 -0400

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 245.4-4ubuntu3.7

---------------
systemd (245.4-4ubuntu3.7) focal; urgency=medium

  [ Andy Chi ]
  * debian/patches/lp1926547-hwdb-60-keyboard-Update-Dell-Privacy-Local-Mic-Mute-.patch
    - Apply upstream patch to correct key and device mapping.
      (LP: #1926547)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=62c3ce6d6b2cab762b24aa610d6d135a67bdd76a

  [ Dan Streetman ]
  * d/p/lp1921696/0001-rfkill-improve-error-logging.patch,
    d/p/lp1921696/0002-rfkill-use-short-writes-and-accept-long-reads.patch:
    Handle rfkill api change in kernel 5.10 (LP: #1921696)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ff0c23ba4fbcfa7f68e98adb6d62798ce54ca1da
  * d/p/lp1929122-network-check-that-received-ifindex-is-valid.patch:
    Check if ifindex is valid (LP: #1929122)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=6378191818bc7d169b657e6f7a2b50cfddb4275e
  * d/p/lp1929560-network-move-set-MAC-and-set-nomaster-operations-out.patch:
    Move link mac and master config out of link_up() (LP: #1929560)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=28cff7ee02a9ebd4ab93026af9fceaa2283725b3
  * d/p/lp1902891-core-mount-mount-command-may-fail-after-adding-the-c.patch:
    Handle failed mount command (LP: #1902891)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=b425189a483d7455db870b0ec5b2443c0eea7d76
  * d/p/resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-with.patch,
    d/p/lp1880258-log-nxdomain-as-debug.patch,
    d/p/lp1785383-resolved-address-DVE-2018-0001.patch:
    - Use upstream patch for DVE-2018-0001 handling (LP: #1785383)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ec45ebfee362ad3e429642f7519e8b88f16dc221

  [ Łukasz 'sil2100' Zemczak ]
  * d/p/lp1664844/0001-network-add-ActivationPolicy-configuration-parameter.patch,
    d/p/lp1664844/0002-test-add-ActivationPolicy-unit-tests.patch,
    d/p/lp1664844/0003-save-link-activation-policy-to-state-file-and-displa.patch:
    - add support for configuring the activation policy for an interface
      (LP: #1664844)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=94f7b72d8128c743f35b308101a87d2c53a4074c

 -- Dan Streetman <email address hidden> Thu, 27 May 2021 11:16:17 -0400

[Launchpad Janitor (janitor)]

This bug was fixed in the package netplan.io - 0.103-0ubuntu3

---------------
netplan.io (0.103-0ubuntu3) impish; urgency=medium

  [ Helmut Grohne ]
  * Annotate Build-Depends with <!nocheck>. (Closes: #961466)

  [ Lukas Märdian ]
  * New upstream release: 0.103
    - Add YAML generator and Keyfile parser for NetworkManager YAML backend
    - Add activation-mode parameter, needs systemd v248+ (LP: #1664844)
    - Make use of systemd-networkd's reload/reconfigure commands
    - Deprecate gateway4 & gateway6 in favor of defaults routes (LP: #1756590)
    - Add io.netplan.Netplan.Generate() DBus method
    - Changed the way of how unmanaged-devices are handled by NetworkManager
    - Improve integration test suite (LP: #1922126)
    Bug fixes:
    - Fix ABI regression introduced in 0.102 (LP: #1922898)
    - Fix netplan set if used across partitions (LP: #1930675)
    - Fix handling of multiple gateway4/gateway6 fields (LP: #1901836)
    - Fix parsing of ovs values with colons (LP: #1913906)
    - Fix failure with set-name and bridges
  * Bump systemd dependency to >= v248 for the activation-mode feature
  * Update debian/watch file
  * Drop patches applied upstream
    - Add 0001-parse-nm-fix-32bit-format-string.patch
    - Add d/p/0002-Revert-cli-apply-reload-reconfigure-networkd-instead.patch
      This reverts the systemd-networkd reload/reconfigure usage, due to a
      bug in systemd (< v249) https://github.com/systemd/systemd/issues/18108
  * Update Standards-Version to 4.5.1, no changes required
  * Add Rules-Requires-Root: no to debian/control
  * Add debian/upstream/metadata file

 -- Lukas Märdian <email address hidden> Fri, 06 Aug 2021 07:56:49 +0200

[Lukas Märdian (slyon)]

The fix was released with netplan v0.103.

[Jerzy Husakowski (jhusakowski)]

If there are users who would like MAAS to generate netplan yaml with explicit support of optional link down interfaces, please let us know. Closing the issue for now.