Open Stack

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 <flavio at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> @flaper87
> Flavio Percoco
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>