Open Stack

> -----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