Open Stack

> We're suffering from a total overload of the term 'metadata' here, and there are
> 3 totally separate things that are somehow becoming mangled

Thanks for the summary. The term "metadata" definitely gets overloaded. I've been experimenting with the "metadata" to see what happens with all of it.

Glance image properties ==> ALL properties are copied to volume_image_metadata in Cinder
Cinder volume_metadata ==> Disappears when uploaded to image in Glance
Cinder volume_image_metadata ==> Core image properties are copied. Rest are lost.

One thing I did was create an image and added properties.  Then I created bootable volume from it.  Then I uploaded the bootable volume to Glance.  When it got back to Glance all the non-core properties were gone.

Was this the intended design? This doesn't seem right.  

Aside from pure user properties, this also would be a problem in Trump's original scenario where you may change options on a volume needed for Nova scheduling or driver settings like hw_scsi_mode. You lose all those properties set when uploading to image. 

Regarding the property protections in Glance, it looks to use RBAC.  It seems to me that if a volume is being uploaded to glance with protected properties and the user doing the copying doesn't have the right roles to create those properties that Glance should reject the upload request. 

Based on the etherpads, the primary motivation for property protections was for an image marketplace, which doesn't seem like there would be the same need for volumes. If property protections were needed for other reasons like restricting properties that are picked up by the scheduler or a driver, then that is a another use case which may affect the cinder client blueprint [1], but seems like it would need to be handled by the Cinder API.

We are trying to work out some concepts on all of this as part of the Graffiti project [2] and a related Horizon blueprint [3] for metadata management. If we put in a UI element for handling the metadata, where should the cinder metadata go? Would it be reasonable to just use volume_image_metadata if the volume is bootable?  Otherwise, use the volume_metadata? 

[1] https://blueprints.launchpad.net/python-cinderclient/+spec/support-volume-image-metadata  
[2] https://wiki.openstack.org/wiki/Graffiti/Architecture#Proposed_Horizon_Concepts  
[3] https://blueprints.launchpad.net/horizon/+spec/tagging 

> -----Original Message-----
> From: Duncan Thomas [mailto:duncan.thomas at gmail.com]
> Sent: Wednesday, May 07, 2014 7:57 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Cinder] Confusion about the respective use cases
> for volume's admin_metadata, metadata and glance_image_metadata
> 
> On 7 May 2014 09:36, Trump.Zhang <zhangleiqiang at gmail.com> wrote:
> > @Tripp, Thanks for your reply and info.
> >
> > I am also thinking if it is proper to add support for updating the
> > volume's glance_image_metadta to reflect the "newest status" of volume.
> >
> > However, there may be alternative ways to achieve it:
> > 1. Using the volume's metatadata
> > 2. Using the volume's admin_metadata
> >
> > So I am wondering which is the most proper method.
> 
> 
> We're suffering from a total overload of the term 'metadata' here, and there are
> 3 totally separate things that are somehow becoming mangled:
> 
> 1. Volume metadata - this is for the tenant's own use. Cinder and nova don't
> assign meaning to it, other than treating it as stuff the tenant can set. It is
> entirely unrelated to glance_metadata 2. admin_metadata - this is an internal
> implementation detail for cinder to avoid every extension having to alter the
> core volume db model. It is not the same thing as glance metadata or
> volume_metadata.
> 
> An interface to modify volume_glance_metadata sounds reasonable, however it
> is *unrelated* to the other two types of metadata. They are different things, not
> replacements or anything like that.
> 
> Glance protected properties need to be tied into the modification API somehow,
> or else it becomes a trivial way of bypassing protected properties. Hopefully a
> glance expert can pop up and suggest a way of achieving this integration.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev