yahoo-eng-team team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

fixed in 0.7.2

** Changed in: cloud-init
       Status: Fix Committed => 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/1100545

Title:
  It should be possible to access the ConfigDrive as a CDROM drive as
  well

Status in Init scripts for use on cloud images:
  Fix Released
Status in “cloud-init” package in Ubuntu:
  Fix Released
Status in “cloud-init” source package in Precise:
  Fix Released
Status in “cloud-init” source package in Quantal:
  Fix Released

Bug description:
  == Begin SRU Information ==
  [Impact]
  'config-drive' is a mechanism for passing data from the hypervisor (or
  cloud platform) to the guest (instance). cloud-init as delivered in 12.10
  correctly implements locating this drive as it is present in OpenStack
  in the folsom release.

  A change is being made in grizzly to allow for the device that contains
  the data to be presented as a CD-ROM rather than a block device as it was
  done in folsom. This changes is primarily driven by non-linux
  hypervisors.

  In order to support Ubuntu cloud images running as a guest on grizzly
  hypervisors that choose to attach the config-drive as a CD-ROM, we need
  to make a change to cloud-init to consider CD-ROMs as a possible source.
  Previously, cloud-init would ignore any device that ended with a digit
  (0-9). Now, it allows the data to come from any block device that is
  not a partition.

  [Test Case]
  Attached to this bug is an ISO that provides config-drive-v2 data.
  The following is the current situation:
   attached-as-cdrom: cloud-init ignores.
   attached-as-disk: cloud-init processes

  After the fix is applied, you will see;
   attached-as-cdrom: cloud-init processes
   attached-as-disk: cloud-init processes

  The provided ISO file simply sets a password for the 'ubuntu' user to
  'passw0rd'. So, verification that the test worked is as easy as logging
  in with 'ubuntu' and 'passw0rd', either via ssh or via the console.

  To perform this test, download a quantal cloud-image from
  http://cloud-images.ubuntu.com and boot it with kvm.

  $ imgurl="http://cloud-images.ubuntu.com/releases/quantal/release-20121218/ubuntu-12.10-server-cloudimg-amd64-disk1.img";
  $ deburl="https://launchpad.net/~smoser/+archive/cloud-init-test/+files/cloud-init_0.7.0-0ubuntu2.3%7Eppa0_all.deb";
  $ isourl="https://bugs.launchpad.net/cloud-init/+bug/1100545/+attachment/3509470/+files/disk.config.gz";

  $ wget $imgurl -O quantal-amd64.img.dist
  $ wget $deburl -O cloud-init.deb
  $ wget $isourl -O cfgdisk.img.dist;

  $ qemu-img convert -O qcow2 quantal-amd64.img.dist disk1.img.dist
  $ qemu-img create -f qcow2 -b disk1.img.dist patched.img.dist

  $ zcat --force cfgdisk.img.dist > cfgdisk.img
  $ chmod 600 cfgdisk.img disk1.img.dist

  # patch the patched.img.dist with new cloud-init
  $ bzr branch lp:~smoser/+junk/backdoor-image ./bi
  $ sudo ./bi/mount-callback-umount patched.img.dist -- \
      sh -ec 'mp=$1; cp cloud-init.deb $mp/tmp &&
              LANG=C chroot $mp dpkg -i /tmp/cloud-init.deb ;
              rm $mp/tmp/cloud-init.deb' --

  $ qemu-img create -f qcow2 -b patched.img.dist patched.img

  # boot patched and unpatched images as cdrom and as disk
  ## unpatched-disk (works)
  $ qemu-img create -f qcow2 -b disk1.img.dist unpatched.img
  $ kvm -m 512 -drive file=unpatched.img,if=virtio -drive file=cfgdisk.img,if=virtio

  ## unpatched-cdrom (config-drive ignored, long boot, fail)
  $ qemu-img create -f qcow2 -b disk1.img.dist unpatched.img
  $ kvm -m 512 -drive file=unpatched.img,if=virtio -cdrom cfgdisk.img

  ## patched-disk (works)
  $ qemu-img create -f qcow2 -b patched.img.dist patched.img
  $ kvm -m 512 -drive file=patched.img,if=virtio -drive file=cfgdisk.img,if=virtio

  ## patched-cdrom (FIXED)
  $ qemu-img create -f qcow2 -b patched.img.dist patched.img
  $ kvm -m 512 -drive file=patched.img,if=virtio -cdrom cfgdisk.img

  The unpatched version with cdrom will take quite a long time to boot, and
  you'll messages on the serial console like:see:
   2013-01-31 18:53:18,185 - DataSourceEc2.py[CRITICAL]: giving up on md after 120

  [Regression Potential]
  The potential for regression is low. The most likely possibility for
  error would be in incorrectly identifying a cd-rom and its content as a
  config-drive.
  == End SRU Information ==


  Currently Cloud-Init requires the ConfigDrive to be available on an
  unpartitioned disk, not a CDROM drive. Windows doesn't recognise this
  type of devices and mounting them requires the extraction of the data
  from the raw disk to an ISO file to be mounted / extracted afterwards.

  It should be optionally possible to access the ConfigDrive as a plain
  CDROM as well to simplify the access on any operating system.

  The raw HDD option compared to the CDROM one offers slightly better
  data access protection especially for the admin_pass field, but as
  this is going to be a deprecated option in the short term, the
  benefits are very limited compared to the additional complications for
  accessing the ConfigDrive data.

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