Comment 0 for bug 954377

After changes made for bug 851159 [1], it seems there were some regressions in the content of the metadata service.
This is causing issues for consumers of that service (cloud-init).

Some things that are broken:
 a.) kernel-id, ramdisk-id show up in the metadata service items list even if there they're not valid for this image.
     The following should be empty output if there are no kernel or ramdisk:
      wget http://169.254.169.254/2009-04-04/meta-data -q -O - | egrep "(kernel|ramdisk)-id"
     This causes a problem when the dataservice is crawled as gets for metadata/kernel-id or ramdisk-id show 404.
 b.) block-device-mapping content is broken
      previously:
    $ python -c 'import boto.utils, pprint; pprint.pprint(boto.utils.get_instance_metadata()["block-device-mapping"])'
    {'ami': 'vda', 'ephemeral0': '/dev/vdb', 'root': '/dev/vda'}
    But now,
    $ python -c 'import boto.utils, pprint; pprint.pprint(boto.utils.get_instance_metadata()["block-device-mapping"])'
    ['ami', 'ephemeral0' 'root']

Then, one thing which seems to have been the case before this change was:
 c.) kernel-id, ramdisk-id, ami-id show 'ami-000000'
     $ ec2metadata --kernel-id --ramdisk-id --ami-id
    ami-00000000
    ami-00000000
    ami-00000000
   That is that 'ami-0000000' was the kernel-id, ramdisk-id and ami-id, rather than the actual values (this was for an instance that did have a kernel and ramdisk).

[1] https://github.com/openstack/nova/commit/1bcf5f5431d3c9620596f5329d7654872235c7ee