Thanks for the summary and detailed explanation. > 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
Does it means that the "volume_metadata" is something like "tagging" for volume? Users can use it to do the filtering or grouping work. > 2. admin_metadata - this is an internal > implementation detail for cinder to avoid every extension having to alter the > core volume db model. I find the original commit and decision of introducing admin_metadta according your info above. Hope it is helpful for others: http://eavesdrop.openstack.org/meetings/cinder/2013/cinder.2013-07-17-16.00.log.txt https://review.openstack.org/#/c/38322 ---------- zhangleiqiang (Trump) Best Regards > -----Original Message----- > From: Duncan Thomas [mailto:duncan.tho...@gmail.com] > Sent: Wednesday, May 07, 2014 9:57 PM > 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 <zhangleiqi...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
