Open Stack

On 28 May 2015 at 19:26, Vladik Romanovsky
<vladik.romanovsky at enovance.com> wrote:
>> As part of the work to object-ify the image metadata dicts, I'm looking
>> at the current way the libvirt driver fetches image metadata for an
>> instance, in cases where the compute manager hasn't already passed it
>> into the virt driver API. I see 2 methods that libvirt uses to get the
>> image metadata
>>
>>  - nova.utils.get_image_from_system_metadata(instance.system_metadata)
>>
>>      It takes the system metadata stored against the instance
>>      and turns it into image  metadata.
>>
>>
>> - nova.compute.utils.get_image_metadata(context,
>>                                          image_api,
>>                                          instance.image_ref,
>>                                        instance)
>>
>>      This tries to get metadata from the image api and turns
>>      this into system metadata
>>
>>      It then gets system metadata from the instance and merges
>>      it from the data from the image
>>
>>      It then calls nova.utils.get_image_from_system_metadata()
>>
>>      IIUC, any changes against the image will override what
>>      is stored against the instance
>>
>>
>>
>> IIUC, when an instance is booted, the image metadata should be
>> saved against the instance. So I'm wondering why we need to have
>> code in compute.utils that merges back in the image metadata each
>> time ?
>>
>> Is this intentional so that we pull in latest changes from the
>> image, to override what's previously saved on the instance ? If
>> so, then it seems that we should have been consistent in using
>> the compute_utils get_image_metadata() API everywhere.
>>
>> It seems wrong though to pull in the latest metadata from the
>> image. The libvirt driver makes various decisions at boot time
>> about how to configure the guest based on the metadata. When we
>> later do changes to that guest (snapshot, hotplug, etc, etc)
>> we *must* use exactly the same image metadata we had at boot
>> time, otherwise decisions we make will be inconsistent with how
>> the guest is currently configured.
>>
>> eg if you set  hw_disk_bus=virtio at boot time, and then later
>> change the image to use hw_disk_bus=scsi, and then try to hotplug
>> a new drive on the guest, we *must* operate wrt hw_disk_bus=virtio
>> because the guest will not have any scsi bus present.
>
> I agree, as well, that we should use the system_metadate instead of
> getting the latest from Glance.
>
> I just wish there would be an easy way to edit it, in order to update
> some keys such as video driver, watchdog action, nic driver.. etc,
> so it would be picked up on hard reboot, for example.

We are trying to build a plan to deal with all those sorts of changes.
The first step is trying to document what we are up to right now.

It feels like much of this should be model-ed as part of the "active" flavor.
But at this point its hard to see what the best way forward will be.

Help with this effort would be very welcome:
https://etherpad.openstack.org/p/YVR-nova-flavors-and-image-properties
... but I am still writing everything up from the summit, so we can
get more folks to join in the action items from the summit sessions.
More on that soon, I hope!

Thanks,
John