yahoo-eng-team team mailing list archive

[James Falcon <2015949@xxxxxxxxxxxxxxxxxx>]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/4101

** Bug watch added: github.com/canonical/cloud-init/issues #4101
   https://github.com/canonical/cloud-init/issues/4101

** Changed in: cloud-init
       Status: Triaged => Expired

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/2015949

Title:
  Ubuntu: cloud-init.service order After=NetworkManager.service not
  possible with Before=sysinit.target

Status in cloud-init:
  Expired

Bug description:
  For Ubuntu Desktop images which prefer NetworkManager as the primary
  network configuration service, provide a mechanism by which cloud-
  init.service can be ordered After=NetworkManager.service and/or
  NetworkManager-wait-online.service.

  
  Use case:
   The Ubuntu desktop live installer ISO prefers using NetworkManager as the primary network backend and cloud-init must order After=NetworkManager.service in these cases to avoid DNS-related bugs during datasource discovery and downloading user-data such as LP: #2008952.

  
  Issue:
  Upstream Ubuntu packaging of systemd cloud-init.service file declares ordering as After=systemd-networkd-wait-online.target[1] and Before=sysinit.target[2]. Adding an new After=NetworkManager.service creatd a systemd ordering cycle which results in cloud-init.service being kicked out of desired systemd boot target goals. The ordering cycle is due to NetworkManager.service `After=dbus.socket` and cloud-init.service declaring `Before=sysinit.target` being incompatible.

  
  Fix Proposal:
  Short-term fix is released which provides an override for cloud-init.service in the livecd-rootfs project[3]

  Mid-term need is to provide an environmental artifact or mechanism at
  systemd-generator timeframe to allow cloud-init.service to order
  After=NetworkManager.service and drop Before=sysinit.target for that
  use-case.

  
  Since NetworkManager.service is After=sysinit.target due to After=dbus.service ordering, cloud-init.service would have to drop it's Before=sysinit.target declarations in order to avoid systemd ordering 
  cycles punting cloud-init out of the boot target.

  Long-term want:
   Ideally, we may want to see NetworkManager.service support for systemd ordering Before=sysinit.target, but that may involve NetworkManager growing the ability to plugin to dbus.service/socket/broker if dbus shows up later than NetworkManager.service. Upstream systemd-networkd made this shift to late-bind to dbus broker as discussed in LP: #1636912 which were eventually accepted for systemd-networkd.service[4][5].

  But NetworkManager growing support for earlier boot before
  dbus.service is probably a longer term goal for NetworkManager than
  cloud-init.service allowing flexibility at systemd generator timeframe
  to prefer NetworkManager over networkd for certain
  images/environments.

  
  [1] https://github.com/canonical/cloud-init/blob/main/systemd/cloud-init.service.tmpl#L11
  [2] https://github.com/canonical/cloud-init/blob/main/systemd/cloud-init.service.tmpl#L33
  [3] livecd-rootfs cloud-init.service overrides https://code.launchpad.net/~chad.smith/livecd-rootfs/+git/livecd-rootfs/+merge/439586
  [4] functional changes allowing networkd to set hostname at some point after networkd start when dbus service shows up https://github.com/systemd/systemd/pull/4710
  [5] networkd dropping After=dbus.service ordering https://github.com/systemd/systemd/issues/4504

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2015949/+subscriptions