[openstack-dev] [glance][nova]improvement-of-accessing-to-glance

Eiichi Aikawa aikawa at mxk.nes.nec.co.jp
Mon Feb 10 05:28:58 UTC 2014


Hi, all,

Thanks for your comment.

Please let me re-explain.
The main purpose of our blueprint is to use network resources more efficiently.

To complete this purpose, we suggested the method of using 2 lists.
We think, as I wrote before, by listing near glance API servers and using them, 
the total amount of data transfer across the networks can be reduced.
Especially, in case of using microserver, communication destination can be
limited within same chassis.

In addition, we think we can resume failed server during glance API server
on secondary list are used. As a result, we can provide higher availability
than current spec.

This bp can provide high efficiency and high availability.
But it seems you think our idea was not so good.

Please let me know your idea which component should be changed.

Regards,
E.Aikawa (aikawa at mxk.nes.nec.co.jp)

--Separator at aikawa@mxk.nes.nec.co.jp:-----Original Message-----
From: Flavio Percoco [mailto:flavio at redhat.com] 
Sent: Tuesday, February 04, 2014 4:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance][nova]improvement-of-accessing-to-glance

On 03/02/14 12:44 -0500, Jay Pipes wrote:
>On Mon, 2014-02-03 at 17:04 +0100, Flavio Percoco 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).
>
>Right, which is why I am recommending to get rid of glance-api below...
>
>> >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.
>
>Cool. Have you pushed a patch for this I can see?

Not to gerrit but I'm hacking on this in my own GH repo first. I'll be submitting that patch soon, hopefully. This is the blueprint[0] for the glance.store work, there you'll find the link to my GH repo! :)

[0] https://blueprints.launchpad.net/glance/+spec/create-store-package

>Thanks, Flavio!

Cheers :)
Flavio

--
@flaper87
Flavio Percoco


More information about the OpenStack-dev mailing list