** Description changed:

+ [Impact]
+ 
+  * resolved does not start early enough in the boot-process preventing
+ DNS resolution to be operational during early boot, for example as
+ required by special early stages of cloud-init, resulting in failure to
+ boot / provision the instance fully.
+ 
+ [Test Case]
+ 
+  * Boot container or a VM with a nocloud-net data source, and a URL pointing 
to the datasource as explained below
+  * Observe that boot completes and provisioning is successful
+  * Check that there are no dns-resolution errors in the cloud-init log / boot 
log
+ 
+ [Regression Potential]
+ 
+  * starting resolved earlier may prevent it from connecting to dbus, and
+ may require a restart later on when re-triggered over dbus. This is on
+ artful only, as in bionic resolved has gained ability to reconnected to
+ dbus post-start. Backporting that, however, is too large for an SRU as
+ it requires sd-bus changes.
+ 
+ [Other Info]
+  
+  * Original bug report.
+ 
  I use no-cloud to test the kernel in CI (I am maintainer of the bcache
  subsystem), and have been running it successfully under 16.04 cloud
  images from qemu, using a qemu command that includes:
  
  -smbios "type=1,serial=ds=nocloud-
  net;s=https://raw.githubusercontent.com/mlyle/mlyle/master/cloud-
  metadata/linuxtst/"
  
  As documented here:
  
  http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
  
  Under the new 17.10 cloud images, this doesn't work: the network comes
  up, but name resolution doesn't work-- /etc/resolv.conf is a symlink to
  a nonexistent file at this point of the boot and systemd-resolved is not
  running.  When I manually hack /etc/resolv.conf in the cloud image to
  point to 4.2.2.1 it works fine.
  
  I don't know if nameservice not working is by design, but it seems like
  it should work.  The documentation states:
  
  "With ds=nocloud-net, the seedfrom value must start with http://,
  https:// or ftp://";
  
  And https is not going to work for a raw IP address.
  
  Related bugs:
-  * bug 1734939: #include fails silently.
+  * bug 1734939: #include fails silently.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1734167

Title:
  DNS doesn't work in no-cloud as launched by ubuntu

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Released
Status in systemd source package in Zesty:
  Fix Released
Status in cloud-init source package in Artful:
  Confirmed
Status in systemd source package in Artful:
  In Progress
Status in systemd source package in Bionic:
  Fix Released

Bug description:
  [Impact]

   * resolved does not start early enough in the boot-process preventing
  DNS resolution to be operational during early boot, for example as
  required by special early stages of cloud-init, resulting in failure
  to boot / provision the instance fully.

  [Test Case]

   * Boot container or a VM with a nocloud-net data source, and a URL pointing 
to the datasource as explained below
   * Observe that boot completes and provisioning is successful
   * Check that there are no dns-resolution errors in the cloud-init log / boot 
log

  [Regression Potential]

   * starting resolved earlier may prevent it from connecting to dbus,
  and may require a restart later on when re-triggered over dbus. This
  is on artful only, as in bionic resolved has gained ability to
  reconnected to dbus post-start. Backporting that, however, is too
  large for an SRU as it requires sd-bus changes.

  [Other Info]
   
   * Original bug report.

  I use no-cloud to test the kernel in CI (I am maintainer of the bcache
  subsystem), and have been running it successfully under 16.04 cloud
  images from qemu, using a qemu command that includes:

  -smbios "type=1,serial=ds=nocloud-
  net;s=https://raw.githubusercontent.com/mlyle/mlyle/master/cloud-
  metadata/linuxtst/"

  As documented here:

  http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html

  Under the new 17.10 cloud images, this doesn't work: the network comes
  up, but name resolution doesn't work-- /etc/resolv.conf is a symlink
  to a nonexistent file at this point of the boot and systemd-resolved
  is not running.  When I manually hack /etc/resolv.conf in the cloud
  image to point to 4.2.2.1 it works fine.

  I don't know if nameservice not working is by design, but it seems
  like it should work.  The documentation states:

  "With ds=nocloud-net, the seedfrom value must start with http://,
  https:// or ftp://";

  And https is not going to work for a raw IP address.

  Related bugs:
   * bug 1734939: #include fails silently.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to