I have a concern to changes required on nova to support kernel_id and ramdisk_id. The concern is, it will need to add 'kernel_id' and 'ramdisk_id' to the server details request. This is in fact a API changes, so not sure how strict nova is for the API changes.
The patch to add the ramdisk_id and kernel_id is simple as followed one, but a lot of test cases need be updated since these test case will check the key in the return value also.
So just want do discuss how important/priority to add back the kernel_id/ramdisk_id back to the meter.
I have a concern to changes required on nova to support kernel_id and ramdisk_id. The concern is, it will need to add 'kernel_id' and 'ramdisk_id' to the server details request. This is in fact a API changes, so not sure how strict nova is for the API changes.
The patch to add the ramdisk_id and kernel_id is simple as followed one, but a lot of test cases need be updated since these test case will check the key in the return value also.
So just want do discuss how important/priority to add back the kernel_ id/ramdisk_ id back to the meter.
--- a/nova/ api/openstack/ compute/ views/servers. py api/openstack/ compute/ views/servers. py common. ViewBuilder) :
"metadata" : self._get_ metadata( instance) ,
"hostId" : self._get_ host_id( instance) or "",
"image" : self._get_ image(request, instance), 'kernel_ id'], 'ramdisk_ id'],
"flavor" : self._get_ flavor( request, instance),
"created" : timeutils. isotime( instance[ "created_ at"]),
"updated" : timeutils. isotime( instance[ "updated_ at"]),
+++ b/nova/
@@ -98,6 +98,8 @@ class ViewBuilder(
+ "kernel_id": instance[
+ "ramdisk_id": instance[