← Back to team overview

group.of.nepali.translators team mailing list archive

[Bug 1602373] Re: cloud-init doesn't always land files that one expects

 

This bug was fixed in the package cloud-init -
0.7.7~bzr1256-0ubuntu1~16.04.1

---------------
cloud-init (0.7.7~bzr1256-0ubuntu1~16.04.1) xenial-proposed; urgency=medium

  * New upstream snapshot.
    - distros/debian.py: fix eni renderer to not render .link files
    - fixes for execution in python2.6.
    - ConfigDrive: fix writing of 'injected' files and legacy networking
      (LP: #1602373)
    - improvements to /etc/network/interfaces rendering including rendering
      of 'lo' devices and sorting attributes within a interface section.
    - fix mcollective module that was completely broken if using python3
      (LP: #1597699)

 -- Scott Moser <smoser@xxxxxxxxxx>  Fri, 15 Jul 2016 13:27:04 -0400

** Changed in: cloud-init (Ubuntu Xenial)
       Status: Fix Committed => Fix Released

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

Title:
  cloud-init doesn't always land files that one expects

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

Bug description:
  ---- Begin SRU Template ----
  [Impact]
  Injected files functionality of OpenStack's config drive is broken.

  [Test Case]
  == Reproduce broken functionality ==
  $ echo "hi mom" > my-file.txt
  $ cat > "user-data" <<"EOF"
  #!/bin/sh
  logfile=/run/my.log
  file="/my-file.txt"
  if [ -e "$file" ]; then
     ( echo "=== PASS: file $file ====" ; cat $file ) | tee -a $logfile
     exit 0
  else
     echo "=== FAIL: no file $file ====" | tee -a $logfile
     exit 0
  fi
  EOF

  openstack server create --key-name=brickies --flavor=m1.small \
    --config-drive=1 --image=$img \
    --user-data=user-data --file=/my-file.txt=my-file.txt \
    injected-file0

  The launched system will have a file in /run/my.log that shows 'FAIL'
  and will not have /my-file.txt on disk.

  == See Fix ==
  # enable proposed
  $ cat > enable-proposed <<"EOF"
  #!/bin/sh
  set -e
  rel=$(lsb_release -sc)
  awk '$1 == "deb" && $2 ~ /ubuntu.com/ {
    printf("%s %s %s-proposed main universe\n", $1, $2, rel); exit(0) };
    ' "rel=$rel" /etc/apt/sources.list |
      tee /etc/apt/sources.list.d/proposed.list
  EOF
  $ sudo sh ./enable-proposed
  $ sudo apt-get update
  $ sudo apt-get install cloud-init

  # Remove /var/lib/cloud and /var/log/cloud-init* to remove state
  # and indicate this is a new instance on reboot
  $ sudo rm -Rf /var/lib/cloud /var/log/cloud-init*
  $ sudo reboot

  Now ssh back in after reboot, you should
  a.) have /my-file.txt
  b.) see PASS in /run/my.log
  c.) see mention of the 'injected file' in /var/log/cloud-init.log

  [Regression Potential]
  Regression potential on Ubuntu should be very small.

  ---- End SRU Template ----

  Trove launches instances using the servers.create() API with some
  files. Trove provides a dictionary of files that it wants on the
  instance and most of the time this works. Nova passes them to the
  launched VM as metadata on config drive.

  Sometimes though, it doesn't.

  When injection fails, I see a cloud-init.log that looks like this:

  https://gist.github.com/amrith/7566d8fef4b6e813cca77e5e3b1f1d5a

  When injection succeeds, I see a cloud-init.log that looks like this:

  https://gist.github.com/amrith/50d9e3050d88ec51e13b0a510bd718c3

  Observe that the one that succeeds properly injects three files:

  /etc/injected_files (which is something I added just for debugging)
  /etc/trove/conf.d/... two files here ...

  On a machine where this injection failed:

  root@m10:/tmp/zz/openstack/content# ls -l /etc/trove
  total 4
  drwxr-xr-x 2 amrith root 4096 Jul 12 16:55 conf.d
  root@m10:/tmp/zz/openstack/content# ls -l /etc/trove/conf.d/
  total 4
  root@m10:/tmp/zz/openstack/content#

  Clearly, no files made it over. Yet, the files are definitely there on
  the config drive ...

  I've mounted the config drive.

  root@m10:/tmp/zz/openstack/content# mount | grep zz
  /dev/sr0 on /tmp/zz type iso9660 (ro,relatime)

  root@m10:/tmp/zz/openstack/content# cd /tmp/zz
  root@m10:/tmp/zz# find .
  .
  ./ec2
  ./ec2/2009-04-04
  ./ec2/2009-04-04/meta-data.json
  ./ec2/latest
  ./ec2/latest/meta-data.json
  ./openstack
  ./openstack/2012-08-10
  ./openstack/2012-08-10/meta_data.json
  ./openstack/2013-04-04
  ./openstack/2013-04-04/meta_data.json
  ./openstack/2013-10-17
  ./openstack/2013-10-17/meta_data.json
  ./openstack/2013-10-17/vendor_data.json
  ./openstack/2015-10-15
  ./openstack/2015-10-15/meta_data.json
  ./openstack/2015-10-15/network_data.json
  ./openstack/2015-10-15/vendor_data.json
  ./openstack/2016-06-30
  ./openstack/2016-06-30/meta_data.json
  ./openstack/2016-06-30/network_data.json
  ./openstack/2016-06-30/vendor_data.json
  ./openstack/content
  ./openstack/content/0000
  ./openstack/content/0001
  ./openstack/content/0002
  ./openstack/latest
  ./openstack/latest/meta_data.json
  ./openstack/latest/network_data.json
  ./openstack/latest/vendor_data.json

  root@m10:/tmp/zz# cd openstack/latest/
  root@m10:/tmp/zz/openstack/latest# cat meta_data.json
  {"files": [{"path": "/etc/injected_files", "content_path": "/content/0000"}, {"path": "/etc/trove/conf.d/guest_info.conf", "content_path": "/content/0001"}, {"path": "/etc/trove/conf.d/trove-guestagent.conf", "content_path": "/content/0002"}], "admin_pass": "pf2ng7tT8JSt", "random_seed": "uSNqQ3udiKspue4y8R8b4gg33Qe6klYYJa8ebvDS0t4i88rq2Owu4yC8TysAfsmsYpno0rbWpWisiTQ3raAOPsx+kGgkrunM9UR5khs/1XRh60tlpKJVIHZnKpLv4PcisLKL2DDoHaaFLV9lPcVtZi3iTqKu6RhcwFyhh+A0mD0xg2G89qACD/RNhWiAuQs4X8le+qgIeoRb3wwg7+4dpujLiqKyx7edDgs9zaEsng21YxO0kv47PiwQf7GoIXObR3xtBYClQQfWQ8a1o35gpDPkPSowqHNKJIxFnIrdFgVHBK5EFTAmwN2JY/GcLwQxLydK02+aalem+bznOpsa1Jl86rNAI9pwltyFYDVz8CGwy46pNYtCOJ2W5WZ+wF4KssE0LkxeWcq7w7CXoFCgz42k13ki0gcHYHw0ieJTMULQT3k65gLwGL2/EsJrZjgil5AaCQhLBLkY2sPhHKYs0k+331QttHHs7PjoX/0as63iNiY62M10givhwyrPDaeYSOAidD0PfRpvVZVcQym/jgKmytV6ZU8DBDwAujGtHjdXK4AovcAvqc96H97arahQr/1SHk8RktyedYjqLC6iYwbSFSHTs+7Fb07MspWKQ2cJLlpmytd/lcZHYAElF/b0VBhR8/eU0dUqdpxjvfGsx8T9/rflMaM5wrDlhad/ikQ=", "uuid": "38731f42-611e-465f-b3e4-1e80aa623caf", "availability_zone": "nova", "hostname": "m10.novalocal", "launch_index": 0, "devices": [], "project_id": "eeec3236ef004821a77ccbd26b81f18f", "name": "m10"}

  root@m10:/tmp/zz/openstack/latest#

  Sure enough, the files I want are in content/0000, 0001 and 0002

  root@m10:/tmp/zz/openstack/content# ls -l
  total 4
  -r--r--r-- 1 root root 1329 Jul 12 16:55 0000
  -r--r--r-- 1 root root  127 Jul 12 16:55 0001
  -r--r--r-- 1 root root 1050 Jul 12 16:55 0002

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