Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

2014-05-21 Thread Day, Phil
-Original Message- From: Tripp, Travis S Sent: 07 May 2014 18:06 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 We're

Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

2014-05-21 Thread Kekane, Abhishek
Hi All, For this purpose we have added a blueprint in cinder for Juno release. https://blueprints.launchpad.net/cinder/+spec/restrict-uploading-volume-to-image Here on the basis of property protection feature of glance we are restricting unintended user from creating image from volume. To

Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

2014-05-18 Thread Mike Perez
On 03:08 Thu 08 May , Zhangleiqiang (Trump) wrote: 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

Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

2014-05-07 Thread Trump.Zhang
@Mike Thanks. Sorry for misleading you. I mean that I know volume already has a bootable field. My question is that once a volume has been created, its glance_image_metadata will be immutable. However, the volume is constantly having blocks changed, so some property of its glance_image_metadata

Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

2014-05-07 Thread Trump.Zhang
@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

Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

2014-05-07 Thread Duncan Thomas
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

Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

2014-05-07 Thread Tripp, Travis S
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.

Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

2014-05-07 Thread Zhangleiqiang (Trump)
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

Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

2014-05-06 Thread Duncan Thomas
'metadata' is a free form key-value space for the tenant to use for their own purposes - it has no semantic meaning to cinder. I expect that other than adding filtering on metadata to the API (if it isn't already there - I can't remember) that it will stay this way. I take your point on the

Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

2014-05-06 Thread Alex Meade
Glance has the concept of 'protected properties' which is really just policies around metadata. property = metadata in glance. https://wiki.openstack.org/wiki/Glance-property-protections -Alex On Tue, May 6, 2014 at 6:50 AM, Duncan Thomas duncan.tho...@gmail.comwrote: 'metadata' is a free

Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

2014-05-06 Thread Trump.Zhang
@Duncan Thanks for your reply and help, :) About I expect that other than adding filtering on metadata to the API (if it isn't already there - I can't remember) that it will stay this way. you mentioned, I am sorry that I am not quite understand what you men. Did you mean using volume metadata

Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

2014-05-06 Thread Trump.Zhang
Thanks for your further instructions. I think the situations I mentioned are the reasonable use cases. They are similar to the bootable volume use cases, user can create an empty volume and install os in it from an image or create bootable volume from instance ([1]). If volume metadata is not

Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

2014-05-06 Thread Mike Perez
On 06:31 Wed 07 May , Trump.Zhang wrote: Thanks for your further instructions. I think the situations I mentioned are the reasonable use cases. They are similar to the bootable volume use cases, user can create an empty volume and install os in it from an image or create bootable volume

Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata

2014-05-06 Thread Tripp, Travis S
A few days ago I entered a client blueprint on the same topic [1], but maybe it has a server side dependency as well? When it comes to scheduling, as far as I have been able to tell from looking at Nova code, the scheduler is only getting volume_image_metadata and not the regular