+1 But we should answer the following question before switching libvirt to utils.get_image_from_system_metadata.
Some differences of utils.get_image_from_system_metadata from compute.utils.get_image_metadata are: 1) Instance metadata has a restriction of property length: long data is stripped to 255 chars. This may cause a fault on loading serialized structure from a metadata property. 2) utils.get_image_from_system_metadata skips properties defined by CONF.non_inheritable_image_properties So the question is: are these facts important for libvirt? On Thu, May 28, 2015 at 10:18 AM, Sahid Orentino Ferdjaoui < [email protected]> wrote: > 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: > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
