[SRU] Azure: Precise should use the same instance ID detection as Trusty

[Stephen A. Zarkos]

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 on Trusty utilizes the system-uuid from SMBIOS as a unique VM ID to identify the instance. Precise still uses the older method of obtaining the Instance ID via the wire server, which is not stable in CRP. Precise should move to use the same instance ID detection logic as Trusty.

Related Bugs:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1506187
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1551419

[Dan Watkins (oddbloke)]

The attached debdiff fixes this for precise.

[Dan Watkins (oddbloke)]

Attached is an updated diff with DEP-3 headers on the patch.

[Dan Watkins (oddbloke)]

The fix for this has been accepted to -proposed and is building/publishing now.

Once done, I'll test upgrade from an existing instance, and create a test image for validation.

[Dan Watkins (oddbloke)]

Grr, I mucked up the changelog, so this bug won't automatically be closed out; we'll go back to tracking in bug 1506187.