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

Maldonado, Facundo N facundo.n.maldonado at intel.com
Fri Jun 27 13:09:52 UTC 2014

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

More information about the OpenStack-dev mailing list