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.maldon...@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.tho...@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.tr...@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@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 -- Duncan Thomas _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
