On Wed, May 20, 2015 at 05:43:07PM +0800, Zhi Yan Liu wrote: > On Wed, May 20, 2015 at 5:23 PM, Zhi Yan Liu <lzy....@gmail.com> wrote: > > On Wed, May 20, 2015 at 5:06 PM, Daniel P. Berrange <berra...@redhat.com> > > wrote: > >> On Wed, May 20, 2015 at 12:01:37AM +0200, Flavio Percoco wrote: > >>> On 19/05/15 17:19 +0100, Daniel P. Berrange wrote: > >>> >In Nova we are attempting to model[1] the glance image metadata and > >>> >properties using the Nova object model (now oslo.versionedobjects). > >>> > > >>> >The one item I'm stuck on understanding is the 'locations' field > >>> >and more specifically the 'metadata' element in each location > >>> >entry > >>> > > >>> > > >>> >In the file glance/api/v2/images.py I can see this description > >>> >of the data format: > >>> > > >>> > 'locations': { > >>> > 'type': 'array', > >>> > 'items': { > >>> > 'type': 'object', > >>> > 'properties': { > >>> > 'url': { > >>> > 'type': 'string', > >>> > 'maxLength': 255, > >>> > }, > >>> > 'metadata': { > >>> > 'type': 'object', > >>> > }, > >>> > }, > >>> > 'required': ['url', 'metadata'], > >>> > }, > >>> > 'description': _('A set of URLs to access the image file kept > >>> > in ' > >>> > 'external store'), > >>> > > >>> > > >>> >As you can see here, 'metadata' is just said to be of type 'object'. > >>> > > >>> >Is there somewhere that actually describes what is valid contents > >>> >for this field ? Is it sufficient to assume the metadata will only > >>> >ever be a dict of strings, or can the metadata be a complex type > >>> >with arbitrarily nested data structures ? > >>> > >>> It's just arbitrary metadata for now, we don't have a specific format. > >>> I'm curious to know if there are folks using this field. We do (did) > >>> have a use case for it. > >> > >> Yep, I'd be curious to understand just what it is used for in practice ? > >> Is the data to be stored in there determined by python code, or by the > >> local administrator or both ? > > > > Yes, It determined by python code in nova as a part of image download > > plugin, and administrator needs to prepare it based on particular > > deployment environment as well. Current a usage is to accelerate image > > download from nfs store to nova compute node, now there is only one > > particular plugin in nova upstream tree [0]. (from the logic in > > _file_system_lookup(), i think a predefined 'id' is needed in the > > metadata of the location entry). > > > > [0] > > https://github.com/openstack/nova/blob/master/nova/image/download/file.py#L150 > > > > zhiyan > > Btw, for your question: > > >>> >Is there somewhere that actually describes what is valid contents > >>> >for this field ? Is it sufficient to assume the metadata will only > >>> >ever be a dict of strings, or can the metadata be a complex type > >>> >with arbitrarily nested data structures ? > > for current nova in-tree image download plugin (above [0]), the schema > of location metadata should be this: > https://github.com/openstack/glance_store/blob/master/glance_store/_drivers/filesystem.py#L72 > > zhiyan
Thankyou, that is useful information. 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev