Hi, I'm not using it yet but had the intention on writing a driver which would download directly from Swift instead of going through Glance for performance reasons. I didn't have time to actually write any code yet or see the actual performance gain (or not) I could get. I only explored the idea with John Dickinson. He told me that it would not be impossible to implement and explained how to implement it so I could benefit from the best Swift performance using some upcoming features of Swift client.
Mathieu -- Mathieu On Tue, Nov 15, 2016 at 1:48 PM, Matt Riedemann <mrie...@linux.vnet.ibm.com> wrote: > The nova.image.download.modules extension point was added back in Havana: > > https://review.openstack.org/#/c/37817/ > > Looks like there was some related work in Glance after the Grizzly summit: > > https://blueprints.launchpad.net/glance/+spec/multiple-image-locations > > This all looks related to the direct image download features that some > Rbd-backed deployments are using for fast snapshots. > > Anyway, the configuration options used with the extension point were > deprecated in nova in the Newton release: > > https://review.openstack.org/#/c/314669/ > > That refers to some vague understanding that this was POC code added to Nova > for Rackspace (by a Red Hat developer?) but was never used in production and > we can just deprecate and remove it from Nova. > > Since I'm a bit worried about vague assertions about who is doing what with > this, I'd like to give the operators a chance to say if they are using this > direct file scheme image download extension point at all, or if not the > in-tree one, at least an out of tree plugin for the > nova.image.download.modules extension point as that will happily load up any > download handler as long as nova can import the module, there is no > whitelist of support handlers. > > I also know that lots of deployments probably aren't at Newton yet so they > haven't seen the release notes about the image_file_url config options being > deprecated so I wanted this to be a further heads up before we go and remove > this code. > > -- > > Thanks, > > Matt Riedemann > > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators