| 2012-03-13 19:46:09 |
Scott Moser |
bug |
|
|
added bug |
| 2012-03-13 19:47:16 |
Scott Moser |
summary |
ec2 metadata service regressed for block-device-mapping, kernel-id, ramdisk-id, ami-id |
ec2 metadata service regressed for block-device-mapping and empty kernel-id, ramdisk-id |
|
| 2012-03-13 19:57:34 |
Scott Moser |
description |
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 |
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 |
|
| 2012-03-13 20:00:30 |
Scott Moser |
description |
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 |
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']
c.) public-keys should not be present in meta-data/ list if none were provided
(wget http://169.254.169.254/latest/meta-data/ -O - -q; echo ) | grep public
d.) if something is a dict it shoudl appear as a directory in the meta-data list
Examples of things that previously had trailing slashes but now do not:
* placement/
* mpi/
* public-keys/
* block-device-mapping/
Then, one thing which seems to have been the case before this change was:
x.) 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 |
|
| 2012-03-13 20:55:26 |
Vish Ishaya |
nova: milestone |
|
essex-rc1 |
|
| 2012-03-13 20:55:42 |
Vish Ishaya |
nova: assignee |
|
Jesse Andrews (anotherjesse) |
|
| 2012-03-13 21:11:36 |
Vish Ishaya |
nova: importance |
Undecided |
High |
|
| 2012-03-13 21:11:38 |
Vish Ishaya |
nova: status |
New |
In Progress |
|
| 2012-03-14 22:40:01 |
OpenStack Infra |
nova: status |
In Progress |
Fix Committed |
|
| 2012-03-20 08:42:13 |
Thierry Carrez |
nova: status |
Fix Committed |
Fix Released |
|
| 2012-04-05 10:54:19 |
Thierry Carrez |
nova: milestone |
essex-rc1 |
2012.1 |
|
