[openstack-dev] [cinder][glance] Update volume-image-metadata proposal

Duncan Thomas duncan.thomas at gmail.com
Fri Jun 27 14:37:58 UTC 2014


I think make it a work item on the blueprint. I honestly haven't
looked to see how much there'd be, just bought it up as a possible
requirement so that it didn't later come as a surprise to glance folks

On 27 June 2014 14:09, Maldonado, Facundo N
<facundo.n.maldonado at intel.com> wrote:
> Should this code cleanup be done separate from the update volume-Image-metadata update bp or should be a work item of it?
>
> -----Original Message-----
> From: Duncan Thomas [mailto:duncan.thomas at gmail.com]
> Sent: Thursday, June 26, 2014 7:29 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [cinder][glance] Update volume-image-metadata proposal
>
> On 25 June 2014 20:08, Tripp, Travis S <travis.tripp at hp.com> wrote:
>
>> Once an instance is launched, the “image” properties are treated the
>> same and lose distinction of whether they came from an image or a
>> bootable volume in Nova. I agree with Facundo that maintaining a
>> consistency between configuration files sounds like a configuration
>> drift risk to me opening the opportunity to bypass protected
>> properties. Also, commands in Cinder like upload-to-image may fail
>> because a bootable volume is created with image properties that Glance doesn’t actually allow.
>>
>> Why not have a single source of truth for protected properties coming
>> from Glance? A small possible downside I see is that the Glance API
>> will get hit more often, but maybe we can optimize that?
>>
>> This does sound like a good topic for the Glance meeting, but since it
>> is a Cinder topic as well, it would be good to get Cinder team feedback.
>
> I've just come from the glance meeting as a cinder representative, and the current plan is to require a copy the config file to both cinder and glance (deployer need to keep these in sync, and sync the protected properties code from glance into cinder (glance are happy to take code cleanups that make this easier; we can consider OSLO or whatever in future but that's a heavy height process for another day, copy and paste will do for now).
>
> There is a risk from config file drift, but there are already plenty of ways to mess up your config files so it isn't a particularly new one, any sensible deployer has tooling round this...
>
> _______________________________________________
> 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



-- 
Duncan Thomas



More information about the OpenStack-dev mailing list