Open Stack

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.day at 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.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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

______________________________________________________________________
Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data.  If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding