[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Jerzy Husakowski]

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.

** Changed in: maas
   Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1664844

Title:
  No distinction between link-up and link-down interfaces

Status in MAAS:
  Won't Fix
Status in netplan:
  Fix Released
Status in netplan.io package in Ubuntu:
  Fix Released
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 Bionic:
  Won't Fix
Status in systemd source package in Bionic:
  Won't Fix
Status in netplan.io source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in netplan.io source package in Groovy:
  Won't Fix
Status in systemd source package in Groovy:
  Fix Released
Status in netplan.io source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released

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 

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Lukas Märdian]

The fix was released with netplan v0.103.

** Changed in: netplan
   Status: In Progress => Fix Released

** Changed in: netplan.io (Ubuntu Focal)
   Status: New => Fix Released

** Changed in: netplan.io (Ubuntu Hirsute)
   Status: New => Fix Released

** Changed in: netplan.io (Ubuntu Groovy)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1664844

Title:
  No distinction between link-up and link-down interfaces

Status in MAAS:
  Triaged
Status in netplan:
  Fix Released
Status in netplan.io package in Ubuntu:
  Fix Released
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 Bionic:
  Won't Fix
Status in systemd source package in Bionic:
  Won't Fix
Status in netplan.io source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in netplan.io source package in Groovy:
  Won't Fix
Status in systemd source package in Groovy:
  Fix Released
Status in netplan.io source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released

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 

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Launchpad Bug Tracker]

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 . (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   Fri, 06 Aug 2021 07:56:49 +0200

** Changed in: netplan.io (Ubuntu)
   Status: In Progress => Fix Released

** Bug watch added: github.com/systemd/systemd/issues #18108
   https://github.com/systemd/systemd/issues/18108

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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:
  Fix Released
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 Bionic:
  Won't Fix
Status in systemd source package in Bionic:
  Won't Fix
Status in netplan.io source package in Focal:
  New
Status in systemd source package in Focal:
  Fix Released
Status in netplan.io source package in Groovy:
  New
Status in systemd source package in Groovy:
  Fix Released
Status in netplan.io source package in Hirsute:
  New
Status in systemd source package in Hirsute:
  Fix Released

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
  

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Dan Streetman]

** Also affects: systemd (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: netplan.io (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: systemd (Ubuntu Bionic)
   Status: New => Won't Fix

** Changed in: netplan.io (Ubuntu Bionic)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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 Bionic:
  Won't Fix
Status in systemd source package in Bionic:
  Won't Fix
Status in netplan.io source package in Focal:
  New
Status in systemd source package in Focal:
  Fix Released
Status in netplan.io source package in Groovy:
  New
Status in systemd source package in Groovy:
  Fix Released
Status in netplan.io source package in Hirsute:
  New
Status in systemd source package in Hirsute:
  Fix Released

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 

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Launchpad Bug Tracker]

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   Thu, 27 May 2021 11:16:17
-0400

** Changed in: systemd (Ubuntu Focal)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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 Released
Status in netplan.io source package in Groovy:
  New
Status in systemd source package in Groovy:
  Fix Released
Status in netplan.io source package in Hirsute:
  New
Status in systemd source package in Hirsute:
  Fix Released

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 

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Launchpad Bug Tracker]

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   Thu, 27 May 2021 11:09:57
-0400

** Changed in: systemd (Ubuntu Hirsute)
   Status: Fix Committed => Fix Released

** Changed in: systemd (Ubuntu Groovy)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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 Released
Status in netplan.io source package in Groovy:
  New
Status in systemd source package in Groovy:
  Fix Released
Status in netplan.io source package in Hirsute:
  New
Status in systemd source package in Hirsute:
  Fix Released

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 

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Łukasz Zemczak]

** Description changed:

  [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 (for 
instance by adding /etc/systemd/network/20-.network) 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.
+ 
+ ---
+ 
+ 
+ [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".
  
- [Test case]
+ [Old Test case]
  Write a netplan configuration:
  
  network:
-   version: 2
-   renderer: networkd
-   ethernets:
- eth0:
-   optional: yes
-   dhcp4: yes
+   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.
  
- [Regression potential]
+ [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 ' on a manual but not auto-started interface in
  ifupdown), but marked administratively disabled. (adminStatus down)

** Changed in: systemd (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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 

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Dan Streetman]

** Also affects: systemd (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: netplan.io (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: netplan.io (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

** Also affects: netplan.io (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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:
  Confirmed
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:
  New
Status in netplan.io source package in Groovy:
  New
Status in systemd source package in Groovy:
  New
Status in netplan.io source package in Hirsute:
  New
Status in systemd source package in Hirsute:
  New

Bug description:
  [Impact]
  Users need to write valid configuration, especially for new features that are 
approved by not yet implemented, such as marking a link "optional".

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

  [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 ' 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/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Dan Streetman]

** Changed in: systemd (Ubuntu)
   Status: Fix Released => Confirmed

** Changed in: systemd (Ubuntu)
   Status: Confirmed => New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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:
  New
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

Bug description:
  [Impact]
  Users need to write valid configuration, especially for new features that are 
approved by not yet implemented, such as marking a link "optional".

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

  [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 ' 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/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Dan Streetman]

** Changed in: systemd (Ubuntu)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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

Bug description:
  [Impact]
  Users need to write valid configuration, especially for new features that are 
approved by not yet implemented, such as marking a link "optional".

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

  [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 ' 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/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Brian Murray]

** Changed in: nplan (Ubuntu Zesty)
   Status: In Progress => Won't Fix

** Changed in: nplan (Ubuntu Artful)
   Status: In Progress => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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:
  In Progress
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

Bug description:
  [Impact]
  Users need to write valid configuration, especially for new features that are 
approved by not yet implemented, such as marking a link "optional".

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

  [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 ' 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/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Mathieu Trudel-Lapierre]

** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

** Tags removed: verification-done-artful verification-done-xenial
verification-done-zesty

** Changed in: systemd (Ubuntu)
   Status: New => In Progress

** Changed in: systemd (Ubuntu Zesty)
   Status: New => Won't Fix

** Package changed: nplan (Ubuntu) => netplan.io (Ubuntu)

** Changed in: systemd (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: netplan.io (Ubuntu Xenial)
   Status: In Progress => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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:
  In Progress
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

Bug description:
  [Impact]
  Users need to write valid configuration, especially for new features that are 
approved by not yet implemented, such as marking a link "optional".

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

  [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 ' 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/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Steve Langasek]

** Changed in: nplan (Ubuntu Xenial)
   Status: Fix Released => In Progress

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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 nplan package in Ubuntu:
  In Progress
Status in nplan source package in Xenial:
  In Progress
Status in nplan source package in Zesty:
  In Progress
Status in nplan source package in Artful:
  In Progress

Bug description:
  [Impact]
  Users need to write valid configuration, especially for new features that are 
approved by not yet implemented, such as marking a link "optional".

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

  [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 ' 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/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Mattias Thidell]

** Changed in: nplan (Ubuntu Xenial)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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 nplan package in Ubuntu:
  In Progress
Status in nplan source package in Xenial:
  Fix Released
Status in nplan source package in Zesty:
  In Progress
Status in nplan source package in Artful:
  In Progress

Bug description:
  [Impact]
  Users need to write valid configuration, especially for new features that are 
approved by not yet implemented, such as marking a link "optional".

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

  [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 ' 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/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Mathieu Trudel-Lapierre]

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)

** Changed in: nplan (Ubuntu)
   Status: Confirmed => In Progress

** Changed in: nplan (Ubuntu Xenial)
   Status: Fix Released => Fix Committed

** Changed in: nplan (Ubuntu Xenial)
   Status: Fix Committed => In Progress

** Changed in: nplan (Ubuntu Zesty)
   Status: Fix Released => In Progress

** Changed in: nplan (Ubuntu Artful)
   Status: Fix Released => In Progress

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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 nplan package in Ubuntu:
  In Progress
Status in nplan source package in Xenial:
  In Progress
Status in nplan source package in Zesty:
  In Progress
Status in nplan source package in Artful:
  In Progress

Bug description:
  [Impact]
  Users need to write valid configuration, especially for new features that are 
approved by not yet implemented, such as marking a link "optional".

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

  [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 ' 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/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Launchpad Bug Tracker]

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   Fri, 02 Mar 2018
17:02:03 -0500

** Changed in: nplan (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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 nplan package in Ubuntu:
  Confirmed
Status in nplan source package in Xenial:
  Fix Released
Status in nplan source package in Zesty:
  Fix Released
Status in nplan source package in Artful:
  Fix Released

Bug description:
  [Impact]
  Users need to write valid configuration, especially for new features that are 
approved by not yet implemented, such as marking a link "optional".

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

  [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 ' 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/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Launchpad Bug Tracker]

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   Fri, 02 Mar 2018
16:50:47 -0500

** Changed in: nplan (Ubuntu Artful)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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 nplan package in Ubuntu:
  Confirmed
Status in nplan source package in Xenial:
  Fix Committed
Status in nplan source package in Zesty:
  Fix Released
Status in nplan source package in Artful:
  Fix Released

Bug description:
  [Impact]
  Users need to write valid configuration, especially for new features that are 
approved by not yet implemented, such as marking a link "optional".

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

  [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 ' 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/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Łukasz Zemczak]

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

** Changed in: nplan (Ubuntu Xenial)
   Status: Fix Released => Fix Committed

** Tags added: verification-needed-xenial

** Tags removed: verification-done-xenial

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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 nplan package in Ubuntu:
  Confirmed
Status in nplan source package in Xenial:
  Fix Committed
Status in nplan source package in Zesty:
  Fix Released
Status in nplan source package in Artful:
  Fix Committed

Bug description:
  [Impact]
  Users need to write valid configuration, especially for new features that are 
approved by not yet implemented, such as marking a link "optional".

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

  [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 ' 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/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Launchpad Bug Tracker]

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
  networkd autostarts or not, but we need to make sure that our generator
  will run at boot, so instead check the state, but only assert it once
  we've added a config file and before checking the state of our dummy
  device.
- Do a bit more to make sure "mix" tests which stack virtual devices are
  as reliable as possible; by setting saner defaults.

nplan (0.25) artful; urgency=medium

  * tests/generate.py: add a test to validate that correct blacklist entries
are added when creating virtual devices.
  * tests/integration.py: clean up after br0 in networkd's test_bridge_mac; as
the remaining interface and udev configuration can confuse NetworkManager
now that it seems to manage random devices it did not create again.
(LP: #1699371)
  * src/nm.c: set the MTU even though we also specify it in systemd-networkd
for consumption by udev. NetworkManager will try to set it and might
otherwise default to the wrong value.
  * src/networkd.c: Set IPv6AcceptRA=no anytime we don't do DHCPv6 (or by the
same config, SLAAC), and don't have static addresses set. This should fix
the cases where unconfigured devices still get an IPv6 address.
(LP: #1655440)
  * src/nm.c: Explicitly set IPv6 method=ignore when IPv6 is otherwise not
configured; this follows the same logic as setting IPv6AcceptRA=no in
networkd, with the exception that NM does not currently disable RAs. When
it does, an unconfigured device for IPv6 will truly be left with no config.

nplan (0.24) artful; urgency=medium

  * debian/control: set Priority to important to make sure we can get into
minimal.

 -- Mathieu Trudel-Lapierre   Thu, 16 Nov 2017
10:43:28 -0500

** Changed in: nplan (Ubuntu Zesty)
   Status: Fix 

[Group.of.nepali.translators] [Bug 1664844] Re: No distinction between link-up and link-down interfaces

[Launchpad Bug Tracker]

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

  * 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
  networkd autostarts or not, but we need to make sure that our generator
  will run at boot, so instead check the state, but only assert it once
  we've added a config file and before checking the state of our dummy
  device.
- Do a bit more to make sure "mix" tests which stack virtual devices are
  as reliable as possible; by setting saner defaults.

nplan (0.25) artful; urgency=medium

  * tests/generate.py: add a test to validate that correct blacklist entries
are added when creating virtual devices.
  * tests/integration.py: clean up after br0 in networkd's test_bridge_mac; as
the remaining interface and udev configuration can confuse NetworkManager
now that it seems to manage random devices it did not create again.
(LP: #1699371)
  * src/nm.c: set the MTU even though we also specify it in systemd-networkd
for consumption by udev. NetworkManager will try to set it and might
otherwise default to the wrong value.
  * src/networkd.c: Set IPv6AcceptRA=no anytime we don't do DHCPv6 (or by the
same config, SLAAC), and don't have static addresses set. This should fix
the cases where unconfigured devices still get an IPv6 address.
(LP: #1655440)
  * src/nm.c: Explicitly set IPv6 method=ignore when IPv6 is