Open Stack

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
<mriedem at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators