Open Stack

On Wed, May 27, 2015 at 02:59:10PM +0100, Daniel P. Berrange 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 ?

As you said during boot time we store in the instance system_metadata
the image properties. Except for some special cases I don't see any
reason to use the method 'get_image_metadata' and we should probably
clean the code in libvirt.

> 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.
> 
> This says to me we should /never/ use the compute_utils
> get_image_metadata() API once the guest is running, and so we
> should convert libvirt to use nova.utils.get_image_from_system_metadata()
> exclusively.
> 
> It also makes me wonder how nova/compute/manager.py is obtaining image
> meta in cases where it passes it into the API and whether that needs
> changing at all.

+1

> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev