Activity log for bug #1100545

Date Who What changed Old value New value Message
2013-01-16 23:22:00 Alessandro Pilotti bug added bug
2013-01-17 00:43:11 Scott Moser cloud-init: importance Undecided Medium
2013-01-17 00:43:11 Scott Moser cloud-init: status New Confirmed
2013-01-17 01:13:25 Launchpad Janitor branch linked lp:cloud-init
2013-01-18 15:13:32 Launchpad Janitor branch linked lp:ubuntu/cloud-init
2013-01-18 15:17:35 Launchpad Janitor branch linked lp:~smoser/ubuntu/precise/cloud-init/sru
2013-01-18 15:19:55 Scott Moser cloud-init: status Confirmed Fix Committed
2013-01-18 15:19:55 Scott Moser cloud-init: assignee Scott Moser (smoser)
2013-01-18 15:20:37 Scott Moser bug task added cloud-init (Ubuntu)
2013-01-18 15:21:44 Scott Moser cloud-init (Ubuntu): importance Undecided Low
2013-01-18 15:21:44 Scott Moser cloud-init (Ubuntu): status New Fix Released
2013-01-18 15:21:44 Scott Moser cloud-init (Ubuntu): assignee Scott Moser (smoser)
2013-01-18 15:21:54 Scott Moser nominated for series Ubuntu Precise
2013-01-18 15:21:54 Scott Moser bug task added cloud-init (Ubuntu Precise)
2013-01-18 15:21:54 Scott Moser nominated for series Ubuntu Quantal
2013-01-18 15:21:54 Scott Moser bug task added cloud-init (Ubuntu Quantal)
2013-01-18 15:22:03 Scott Moser cloud-init (Ubuntu Precise): status New Triaged
2013-01-18 15:22:06 Scott Moser cloud-init (Ubuntu Quantal): status New Triaged
2013-01-18 15:22:09 Scott Moser cloud-init (Ubuntu Precise): importance Undecided Medium
2013-01-18 15:22:12 Scott Moser cloud-init (Ubuntu Quantal): importance Undecided Medium
2013-01-18 15:22:15 Scott Moser cloud-init (Ubuntu Precise): assignee Scott Moser (smoser)
2013-01-18 15:22:17 Scott Moser cloud-init (Ubuntu Quantal): assignee Scott Moser (smoser)
2013-01-18 15:28:18 Launchpad Janitor branch linked lp:~smoser/ubuntu/quantal/cloud-init/sru
2013-01-31 14:43:43 Scott Moser description 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. == 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. Booting a kvm instance with iso as cdrom: kvm -drive disk1.img,if=virtio -cdrom lp-1077020.iso Booting a kvm instance with iso as disk: kvm -drive disk1.img,if=virtio -drive lp-1077020.iso,if=virtio lp-1077020.iso [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.
2013-01-31 19:38:48 Scott Moser attachment added example config drive disk (iso) https://bugs.launchpad.net/cloud-init/+bug/1100545/+attachment/3509470/+files/disk.config.gz
2013-01-31 20:03:41 Scott Moser 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. Booting a kvm instance with iso as cdrom: kvm -drive disk1.img,if=virtio -cdrom lp-1077020.iso Booting a kvm instance with iso as disk: kvm -drive disk1.img,if=virtio -drive lp-1077020.iso,if=virtio lp-1077020.iso [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. == 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.
2013-02-07 20:11:26 Brian Murray cloud-init (Ubuntu Quantal): status Triaged Fix Committed
2013-02-07 20:11:29 Brian Murray bug added subscriber Ubuntu Stable Release Updates Team
2013-02-07 20:11:34 Brian Murray bug added subscriber SRU Verification
2013-02-07 20:11:43 Brian Murray tags verification-needed
2013-02-08 04:03:48 Scott Moser tags verification-needed verification-done
2013-02-15 10:29:11 Launchpad Janitor cloud-init (Ubuntu Quantal): status Fix Committed Fix Released
2013-02-19 18:27:55 Clint Byrum cloud-init (Ubuntu Precise): status Triaged Fix Committed
2013-02-19 18:28:00 Clint Byrum tags verification-done
2013-02-19 18:28:01 Clint Byrum tags verification-needed
2013-02-19 21:53:22 Scott Moser tags verification-needed verification-done
2013-02-27 02:42:37 Colin Watson removed subscriber Ubuntu Stable Release Updates Team
2013-02-27 02:43:11 Launchpad Janitor cloud-init (Ubuntu Precise): status Fix Committed Fix Released
2013-05-15 20:02:04 Scott Moser cloud-init: status Fix Committed Fix Released
2013-08-28 11:32:39 Launchpad Janitor branch linked lp:~ubuntu-branches/ubuntu/precise/cloud-init/precise-proposed
2013-08-28 11:32:56 Launchpad Janitor branch linked lp:~ubuntu-branches/ubuntu/precise/cloud-init/precise-updates
2013-08-28 11:33:11 Launchpad Janitor branch linked lp:~ubuntu-branches/ubuntu/quantal/cloud-init/quantal-proposed
2013-08-28 11:33:22 Launchpad Janitor branch linked lp:~ubuntu-branches/ubuntu/quantal/cloud-init/quantal-updates
2023-05-09 23:12:42 James Falcon bug watch added https://github.com/canonical/cloud-init/issues/2349