group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1664844@xxxxxxxxxxxxxxxxxx>]

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 <slyon@xxxxxxxxxx>  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
  handling code paths, so regressions could appear in how networkd
  manages links - maybe by suddenly certain interfaces not getting
  brought up as they were before.  By code inspection, the
  implementation defaults to ACTIVATION_POLICY_UP as the default,
  equivalent to the current behavior, so this risk is small.

  ---

  [Original Description]

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

  [Old Test case]
  Write a netplan configuration:

  network:
    version: 2
    renderer: networkd
    ethernets:
      eth0:
        optional: yes
        dhcp4: yes

  And run 'netplan apply'. Netplan should write configuration for the
  link and not error out with a syntax error.

  [Old Regression potential]
  This has a minimal potential for regression: the new keyword was added to be supported already by consumers of netplan (users, cloud-init) so that they could start writing config with the new key and that configuration to be seen as valid by netplan before the backend is implemented. There is no functional change besides allowing for the value to exist in a netplan configuation.

  ---

  If I define an interface in netplan (even one which has no DHCP type
  and no addresses), it's not possible to determine if its adminStatus
  should be enabled (link up) or disabled (link down).

  I can completely exclude an interface from the netplan configuration,
  but I think that implies that not only its adminStatus is "disabled"
  by default, but also netplan will not be able to do anything "nice"
  for the interface, such as rename it to what the user specified in
  MAAS.

  If I include the interface but don't specify any addresses or DHCP, it
  isn't clear if it will be link up (my current assumption) or link
  down.

  There should be a way to allow an interface to be recognized by
  netplan (and even partially configured, waiting for the user to run
  something like 'ifup <interface>' on a manual but not auto-started
  interface in ifupdown), but marked administratively disabled.
  (adminStatus down)

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1664844/+subscriptions