Open Stack

+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 <
sahid.ferdjaoui at redhat.com> 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:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150528/c00512e5/attachment.html>