During review of the proposed patch, the concern was raised that cloud- init will migrate to using the new instance ID and thus run first-boot provisioning. In order to mitigate this, cloud-init needs to migrate existing instances to the new instance ID during installation of the upgraded package.
Attached patch is proposed for debian/cloud-init.postinst ** Description changed: - The Azure datasource currently uses the InstanceID from the - SharedConfig.xml file. On our new CRP stack, this ID is not guaranteed - to be stable and could change if the VM is deallocated. If the - InstanceID changes then cloud-init will attempt to reprovision the VM, - which could result in temporary loss of access to the VM. + SRU JUSTIFICATION + + [IMPACT] On Azure, the InstanceID is currently detected via a fabric + provided XML file. With the new CRP stack, this ID is not guaranteed to + be stable. As a result instances may go re-provision upon reboot. + + [FIX] Use DMI data to detect the instance ID and migrate existing + instances to the new ID. + + [REGRESSION POTENTIAL] The fix is both in the cloud-init code and in the + packaging. If the instance ID is not properly migrated, then a reboot + may trigger re-provisioning. + + [TEST CASES] + 1. Boot instance on Azure. + 2. Apply cloud-init from -proposed. A migration message should apply. + 3. Get the new instance ID: + $ sudo cat /sys/class/dmi/id/product_uuid + 4. Confirm that /var/lib/cloud/instance is a symlink to /var/lib/cloud/instances/<UUID from step 3> + 5. Re-install cloud-init and confirm that migration message is NOT displayed. + + [TEST CASE 2] + 1. Build new cloud-image from -proposed + 2. Boot up instance + 3. Confirm that /sys/class/dmi/id/product_uuid is used to get instance ID (see /var/log/cloud-init.log) + + + [ORIGINAL REPORT] + The Azure datasource currently uses the InstanceID from the SharedConfig.xml file. On our new CRP stack, this ID is not guaranteed to be stable and could change if the VM is deallocated. If the InstanceID changes then cloud-init will attempt to reprovision the VM, which could result in temporary loss of access to the VM. Instead cloud-init should switch to use the VM Unique ID, which is guaranteed to be stable everywhere for the lifetime of the VM. The VM unique ID is explained here: https://azure.microsoft.com/en-us/blog /accessing-and-using-azure-vm-unique-id/ In short, the unique ID is available via DMI, and can be accessed with the command 'dmidecode | grep UUID' or even easier via sysfs in the file "/sys/devices/virtual/dmi/id/product_uuid". Steve ** Patch added: "cloud-init postinst patch for applying new instance ID to existing instances" https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1506187/+attachment/4520856/+files/lp-1506187-postinst.diff -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cloud-init in Ubuntu. https://bugs.launchpad.net/bugs/1506187 Title: [SRU] Azure: cloud-init should use VM unique ID To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1506187/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
