I have a related BP: https://blueprints.launchpad.net/glance/+spec/image-location-selection-strategy
IMO, as I mentioned in its description, it can be applied in glance and consumer (glance's client) both sides: in glance internal, this can be used for "image-download" handling and "direct_url_ selection logic; For consumer side, like Nova, it can be used to select efficient image storage for particular compute node, actually it allow customer/ISV implement their own strategy plugin. And we have a near plan, as flaper87 mentioned above, I believe we will separate glance store code *and* image-location-selection-strategy stuff to an independent package under glance project, at that time we can change Nova to leverage it, and admin/operator can via selection-strategy related options to configure Nova but Glance (agree to Jay on this point) zhiyan On Tue, Feb 4, 2014 at 12:04 AM, Flavio Percoco <fla...@redhat.com> wrote: > On 03/02/14 10:13 -0500, Jay Pipes wrote: >> >> On Mon, 2014-02-03 at 10:03 +0100, Flavio Percoco wrote: >>> >>> IMHO, the bit that should really be optimized is the selection of the >>> store nodes where the image should be downloaded from. That is, >>> selecting the nearest location from the image locations and this is >>> something that perhaps should happen in glance-api, not nova. >> >> >> I disagree. The reason is because glance-api does not know where nova >> is. Nova does. > > > Nova doesn't know where glance is either. More info is required in > order to finally do something smart here. Not sure what the best > approach is just yet but as mentioned in my previous email I think > focusing on the stores for now is the thing to do. (As you pointed out > bellow too). > > >> >> I continue to think that the best performance gains will come from >> getting rid of glance-api entirely, putting the block-streaming bits >> into a separate Python library, and having Nova and Cinder pull >> image/volume bits directly from backend storage instead of going through >> the glance middleman. > > > > This is exactly what we're doing by pulling glance.store into its own > library. I'm working on this myself. We are not completely getting rid > of glance-api but we're working on not depending on it to get the > image data. > > Cheers, > flaper > > >> >> Best, >> -jay >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > -- > @flaper87 > Flavio Percoco > > _______________________________________________ > 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
