yahoo-eng-team team mailing list archive

[Bug Watch Updater <1771382@xxxxxxxxxxxxxxxxxx>]

** Changed in: cloud-init (openSUSE)
       Status: Confirmed => Fix Released

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

Title:
  ds-identify: fails to recognize NoCloud datasource on boot cause it
  does not have /sbin in $PATH and thus does not find blkid

Status in cloud-init:
  Fix Committed
Status in cloud-init package in openSUSE:
  Fix Released

Bug description:
  cloud-init 18.2 from
  http://download.opensuse.org/repositories/Cloud:/Tools/SLE_12_SP3/ on
  SLES 12 SP 3 with NoCloud data source via Cloud Init drive made by
  Proxmox.

  On SLES 12 SP3 NoCloud data source was not working, despite

  slestemplate:~ # blkid -c /dev/null -o export
  […]
  DEVNAME=/dev/sr0
  UUID=2018-05-15-16-34-27-00
  LABEL=cidata
  TYPE=iso9660
  […]

  with necessary files on it. blkid gives 0 as returncode

  Why?

  I only kept parts of the output:

  slestemplate:/etc/cloud # cat /run/cloud-init/ds-identify.log 
  [up 8.63s] ds-identify 
  policy loaded: mode=search report=false found=all maybe=all notfound=disabled
  no datasource_list found, using default: MAAS ConfigDrive NoCloud AltCloud Azure Bigstep CloudSigma CloudStack DigitalOcean AliYun Ec2 GCE OpenNebula OpenStack OVF SmartOS Scaleway Hetzner IBMCloud
  ERROR: failed running [127]: blkid -c /dev/null -o export
  […]
  FS_LABELS=unavailable:error
  ISO9660_DEVS=unavailable:error

  It might have been that I did not yet add the CloudInit drive in
  Proxmox yet.

  A subsequent call to

  slestemplate:~ # /usr/lib/cloud-init/ds-identify

  did not yet yield a different result.

  Only by analysing the source I found that it caches results and I can
  use the `--force` option to override this. I did this and the NoCloud
  datasource got detected properly. Apparently this is cached now.

  The tool would only inform of the caching as a DEBUG message. However
  I set logging to INFO for all parts of Cloud Init as the FileHandler
  clutters the log with tons of messages how many bytes it read from
  each file. Sure, I could use INFO only for FileHandler.

  Several issues reduce the ease of administration here:

  1. Don´t cache errors. Really… just… don´t.

  2. Don´t cache errors almost *silently* (just as a debug message).

  3. Decide wisely what is a debug message and what is not.

  4. A search for `ds-identify` in the documentation available at
  https://cloudinit.readthedocs.io/en/latest/ did not yield any result.

  5. And in general: Keep it short and simple.

  IMHO the first is the most important: Don´t cache errors. If the
  resource now is there, recognize it, without further discussion.

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