group.of.nepali.translators team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

Hello,
An SRU upload of cloud-init for 16.04 that contains a fix for this bug has been made under bug 1595302.  Please track that bug if you are interested.

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
       Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
       Status: New => In Progress

** Changed in: cloud-init (Ubuntu Xenial)
     Assignee: (unassigned) => Scott Moser (smoser)

-- 
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/1577844

Title:
  Drop unnecessary blocking of all net udev rules

Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  In Progress

Bug description:
  cloud-inits networking setup currently jumps through a lot of bad
  hoops to make sure that ifup@ does not run until after cloud-init-
  local.service. This includes blocking udev rules for an indefinite
  time, which is racy, a potential deadlock, and highly non-elegant.

  This is also not necessary: while ifupdown's net udev rule certainly
  can fire before cloud-init-local, it only asynchronously starts
  ifup@.service which will be deferred until after network-pre.target
  and thus after cloud-init-local.service.

  -------
  Original description, which turned out to be completely false and just us being misled:

  ifup@.service can (and often does) run for a particular interface
  before networking.service runs. This is brittle as during early boot
  ifup is prone to fail: / might still be read-only, /var might not yet
  exist or be writable, dhclient-enter-hooks.d/ or if-up.d/ hooks might
  silently fail, etc. It is also unnecessary as networking.service will
  bring up all "auto" and all present "allow-hotplug" interfaces anyway,
  and it runs at the right time.

  We should make either 80-ifupdown.rules or ifup@.service ignore events
  until networking.service is active, or wait until after it has run
  (slower, but avoids race conditions when hotplug events happen while
  networking.service is running). Thus we need to add
  After=networking.service to ifup@.service, so that this only does
  stuff after doing the "coldplug" configuration.

  This also affects cloud-init's setup of networking: this currently
  jumps through a lot of bad hoops to make sure that ifup@ does not run
  until after cloud-init-local.service. This includes blocking udev
  rules for an indefinite time, which is racy, a potential deadlock, and
  highly non-elegant.

  https://bugs.debian.org/752919 is related to this issue.

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