Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata
-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 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. OK I won't even try to bring Nova's three types of metadata into the discussion then. Glance image properties == ALL properties are copied to volume_image_metadata in Cinder Let's just limit this thread to this one, since that's the one that is partly mutable in Glance and becomes immutable in Cinder 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. No it is still needed. Consider the case where there is a licensed image in Glance. That license key, which will be passed through to the billing system has to be immutable and has to be availabe to Nova for any instance that is running a copy of that image. Create a snapshot in Glance, the key needs to be there. Create a bootable volume in Cinder, the key needs to be there, etc, etc.So both Nova and Cinder have to copy the Glance Image properties whenever they create a copy of an image. The full set of paths where the image properties need to be copied are: - When Cinder creates a bootable volume from an Image on Glance - When Cinder creates a snapshot or copy of a bootable volume - When Nova creates a snapshot in Glance from a running instance (So Nova has to have a copy of the properties of the image the instance was booted from - the image in Glance can be deleted while the instance is running) The issue is that the set of Glance Image Properties that are copied need are a combination of muatable and immutable values - but that distinction is lost when they are copied into Cinder. I'm not even sure if you can query Glance to find out if a property is mutable or not. So to make Cinder and Glance consistent I think we would need: 1) A way to find out from Glance is a property is mutable or not 2) A way in Cinder to mark a property as mutable or immutable I don't think Nova needs to know the difference, since it only ever creates snapshots in Glance - and Glance already knows what can and can't be changed. Phil -Original Message- From: Duncan Thomas [mailto:duncan.tho...@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 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
Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata
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 differentiate between core and custom properties we are adding new parameter in cinder.conf which will store core properties of the image. glance_core_properties = 'container_format', 'disk_format', 'min_disk', 'min_ram', 'name', 'size' Please share your thoughts on the same. Thanks, Abhishek -Original Message- From: Day, Phil [mailto:philip@hp.com] Sent: Thursday, May 22, 2014 1:19 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 -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 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. OK I won't even try to bring Nova's three types of metadata into the discussion then. Glance image properties == ALL properties are copied to volume_image_metadata in Cinder Let's just limit this thread to this one, since that's the one that is partly mutable in Glance and becomes immutable in Cinder 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. No it is still needed. Consider the case where there is a licensed image in Glance. That license key, which will be passed through to the billing system has to be immutable and has to be availabe to Nova for any instance that is running a copy of that image. Create a snapshot in Glance, the key needs to be there. Create a bootable volume in Cinder, the key needs to be there, etc, etc.So both Nova and Cinder have to copy the Glance Image properties whenever they create a copy of an image. The full set of paths where the image properties need to be copied are: - When Cinder creates a bootable volume from an Image on Glance - When Cinder creates a snapshot or copy of a bootable volume - When Nova creates a snapshot in Glance from a running instance (So Nova has to have a copy of the properties of the image the instance was booted from - the image in Glance can be deleted while the instance is running) The issue is that the set of Glance Image Properties that are copied need are a combination of muatable and immutable values - but that distinction is lost when they are copied into Cinder. I'm not even sure if you can query Glance to find out if a property is mutable or not. So to make Cinder and Glance consistent I think we would need: 1) A way to find out from Glance is a property is mutable or not 2) A way in Cinder to mark a property as mutable or immutable I don't think Nova needs to know the difference, since it only ever creates snapshots in Glance - and Glance already knows what can and can't be changed. Phil -Original Message- From: Duncan Thomas [mailto:duncan.tho...@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 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
Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata
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 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. I don't know what the actual usage users are doing with volume metadata, but it would be possible to filter by it when listing volumes. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata
@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 will become overdue. The example is the hw_scsi_mode property of glance_image_metadata, which will affect the scsi controller used when booting from volume. 2014-05-07 11:09 GMT+08:00 Mike Perez thin...@gmail.com: 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 from instance ([1]). If volume metadata is not intended to be interpreted by cinder or nova as meaning anything, maybe Cinder needs to add support for updating some of glance_image_metadata of volume or introduce new property for volume like bootable ? I don't think these two methods are good either. [1] https://blueprints.launchpad.net/cinder/+spec/add-bootable-option Volume already has a bootable field: https://github.com/openstack/cinder/blob/master/cinder/db/sqlalchemy/models.py#L122 -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- --- Best Regards Trump.Zhang ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata
@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. 2014-05-07 12:32 GMT+08:00 Tripp, Travis S travis.tr...@hp.com: 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 cinder_metadata. So, if you want to add some volume_image_metadata for scheduler filtering or for passing compute driver options through after creating a volume, there doesn't seem to be a way to do this from the python-cinderclient. If I'm wrong, please correct me. [1] https://blueprints.launchpad.net/python-cinderclient/+spec/support-volume-image-metadata -Original Message- From: Mike Perez [mailto:thin...@gmail.com] Sent: Tuesday, May 06, 2014 9:10 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 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 from instance ([1]). If volume metadata is not intended to be interpreted by cinder or nova as meaning anything, maybe Cinder needs to add support for updating some of glance_image_metadata of volume or introduce new property for volume like bootable ? I don't think these two methods are good either. [1] https://blueprints.launchpad.net/cinder/+spec/add-bootable-option Volume already has a bootable field: https://github.com/openstack/cinder/blob/master/cinder/db/sqlalchemy/model s.py#L122 -- Mike Perez ___ 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 -- --- Best Regards Trump.Zhang ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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
Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata
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.tho...@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 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
Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata
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
Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata
'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 glance metadata. Glance has the concept to mutable and immutable metadata, maybe we can do something with that? I'll ask somebody who knows more about glance than me and get back to you... On 4 May 2014 10:33, Zhangleiqiang (Trump) zhangleiqi...@huawei.com wrote: Hi, stackers: I have some confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata. I know glance_image_metadata comes from image which is the volume created from, and it is immutable. Glance_image_metadata is used for many cases, such as billing, ram requirement, etc. And it also includes property which can effects the use-pattern of volume, such as volumes with hw_scsi_mode=virtio-scsi will be supposed that there is corresponding virtio-scsi driver installed and will be used as a device of virtio-scsi controller which has higher performance when booting from it with scsi bus type. However, volume is constantly having blocks changed, which may result in situations as follows: 1. A volume not created from image or created from image without hw_scsi_mode property at first but then has the virtio-scsi driver manually installed, there will be no method to make the volume used with virito-scsi controller when booting from it. 2. If a volume was created from an image with hw_scsi_mode property at first, and then the virtio-scsi driver in the instance is uninstalled, there will be no method to make the volume not used with virtio-scsi controller when booting from it. For the first situation, is it suitable to set corresponding metadata to volume? Should we use metadata or admin_metadata? I notice that volumes will have attach_mode and readonly admin_metadata and empty metadata after created, and I can't find the respective use cases for admin_metada and metadata. For the second situation, what is the better way to handle it? Any advice? -- zhangleiqiang (Trump) Best Regards ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata
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 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 glance metadata. Glance has the concept to mutable and immutable metadata, maybe we can do something with that? I'll ask somebody who knows more about glance than me and get back to you... On 4 May 2014 10:33, Zhangleiqiang (Trump) zhangleiqi...@huawei.com wrote: Hi, stackers: I have some confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata. I know glance_image_metadata comes from image which is the volume created from, and it is immutable. Glance_image_metadata is used for many cases, such as billing, ram requirement, etc. And it also includes property which can effects the use-pattern of volume, such as volumes with hw_scsi_mode=virtio-scsi will be supposed that there is corresponding virtio-scsi driver installed and will be used as a device of virtio-scsi controller which has higher performance when booting from it with scsi bus type. However, volume is constantly having blocks changed, which may result in situations as follows: 1. A volume not created from image or created from image without hw_scsi_mode property at first but then has the virtio-scsi driver manually installed, there will be no method to make the volume used with virito-scsi controller when booting from it. 2. If a volume was created from an image with hw_scsi_mode property at first, and then the virtio-scsi driver in the instance is uninstalled, there will be no method to make the volume not used with virtio-scsi controller when booting from it. For the first situation, is it suitable to set corresponding metadata to volume? Should we use metadata or admin_metadata? I notice that volumes will have attach_mode and readonly admin_metadata and empty metadata after created, and I can't find the respective use cases for admin_metada and metadata. For the second situation, what is the better way to handle it? Any advice? -- zhangleiqiang (Trump) Best Regards ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas ___ 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
Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata
@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 was not the right way for the first situation I mentioned in ealier mail? 2014-05-06 18:50 GMT+08:00 Duncan Thomas duncan.tho...@gmail.com: '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 glance metadata. Glance has the concept to mutable and immutable metadata, maybe we can do something with that? I'll ask somebody who knows more about glance than me and get back to you... On 4 May 2014 10:33, Zhangleiqiang (Trump) zhangleiqi...@huawei.com wrote: Hi, stackers: I have some confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata. I know glance_image_metadata comes from image which is the volume created from, and it is immutable. Glance_image_metadata is used for many cases, such as billing, ram requirement, etc. And it also includes property which can effects the use-pattern of volume, such as volumes with hw_scsi_mode=virtio-scsi will be supposed that there is corresponding virtio-scsi driver installed and will be used as a device of virtio-scsi controller which has higher performance when booting from it with scsi bus type. However, volume is constantly having blocks changed, which may result in situations as follows: 1. A volume not created from image or created from image without hw_scsi_mode property at first but then has the virtio-scsi driver manually installed, there will be no method to make the volume used with virito-scsi controller when booting from it. 2. If a volume was created from an image with hw_scsi_mode property at first, and then the virtio-scsi driver in the instance is uninstalled, there will be no method to make the volume not used with virtio-scsi controller when booting from it. For the first situation, is it suitable to set corresponding metadata to volume? Should we use metadata or admin_metadata? I notice that volumes will have attach_mode and readonly admin_metadata and empty metadata after created, and I can't find the respective use cases for admin_metada and metadata. For the second situation, what is the better way to handle it? Any advice? -- zhangleiqiang (Trump) Best Regards ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- --- Best Regards Trump.Zhang ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata
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 intended to be interpreted by cinder or nova as meaning anything, maybe Cinder needs to add support for updating some of glance_image_metadata of volume or introduce new property for volume like bootable ? I don't think these two methods are good either. [1] https://blueprints.launchpad.net/cinder/+spec/add-bootable-option 2014-05-07 1:00 GMT+08:00 Duncan Thomas duncan.tho...@gmail.com: On 6 May 2014 14:46, Trump.Zhang zhangleiqi...@gmail.com wrote: Did you mean using volume metadata was not the right way for the first situation I mentioned in ealier mail? Correct. Volume metadata is entirely for the tenant to use, it is not interpreted by cinder or nova as meaning anything. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- --- Best Regards Trump.Zhang ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata
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 from instance ([1]). If volume metadata is not intended to be interpreted by cinder or nova as meaning anything, maybe Cinder needs to add support for updating some of glance_image_metadata of volume or introduce new property for volume like bootable ? I don't think these two methods are good either. [1] https://blueprints.launchpad.net/cinder/+spec/add-bootable-option Volume already has a bootable field: https://github.com/openstack/cinder/blob/master/cinder/db/sqlalchemy/models.py#L122 -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Confusion about the respective use cases for volume's admin_metadata, metadata and glance_image_metadata
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 cinder_metadata. So, if you want to add some volume_image_metadata for scheduler filtering or for passing compute driver options through after creating a volume, there doesn't seem to be a way to do this from the python-cinderclient. If I'm wrong, please correct me. [1] https://blueprints.launchpad.net/python-cinderclient/+spec/support-volume-image-metadata -Original Message- From: Mike Perez [mailto:thin...@gmail.com] Sent: Tuesday, May 06, 2014 9:10 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 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 from instance ([1]). If volume metadata is not intended to be interpreted by cinder or nova as meaning anything, maybe Cinder needs to add support for updating some of glance_image_metadata of volume or introduce new property for volume like bootable ? I don't think these two methods are good either. [1] https://blueprints.launchpad.net/cinder/+spec/add-bootable-option Volume already has a bootable field: https://github.com/openstack/cinder/blob/master/cinder/db/sqlalchemy/model s.py#L122 -- Mike Perez ___ 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
