Open Stack

Hello,

> I added one additional materials to bp page. Please see this.

I added link to following wiki to bp page. Please check this!

https://wiki.openstack.org/wiki/ImprovementOfAccessingToGlanceAPIServer

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

-----Original Message-----
From: Aikawa, Eiichi(相川, 英一) 
Sent: Wednesday, February 19, 2014 6:33 PM
To: 'openstack-dev at lists.openstack.org'
Cc: Takemori, Seishi(武森, 清市)
Subject: RE: [openstack-dev] [glance][nova]improvement-of-accessing-to-glance

Hello,

Thanks for your comment and sorry for my late response.

>IMHO, we should be adding more info the endpoint lists (like location) 
>in keystone and use that info from Glance client to determine which 
>glance-api the compute should talk to.

I understand your idea is one of the possibility, but it's not enough as a solution to the problem we think.

We think keystone cannot control because keystone can't know which Glance servers and Nova are located in the same chassis.

We think the suggestion of our bp, each Nova has each server list to use Glance API server in same chassis at first, is reasonable and simple way to control.

I added one additional materials to bp page. Please see this.

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



-----Original Message-----
From: Flavio Percoco [mailto:flavio at redhat.com]
Sent: Tuesday, February 11, 2014 6:00 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Takemori, Seishi(武森, 清市)
Subject: Re: [openstack-dev] [glance][nova]improvement-of-accessing-to-glance

On 10/02/14 05:28 +0000, Eiichi Aikawa wrote:
>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.

I understood that. I just don't think Nova is the right place to do it. I think this requires more than a list of weighted glance-api nodes in the compute server. If we want do this right, IMHO, we should be adding more info the endpoint lists (like location) in keystone and use that info from Glance client to determine which glance-api the compute should talk to.

I'm assuming you're planning to add a new configuration option to Nova into which you'll be able to specify a list of Glance nodes. If this is True, I'd highly discourage doing that. Nova has enough configuration options already and the compute nodes configs are quite different already. Adding this would mean making nova do things it shouldn't do and making it's configuration more complex than it is already.

That said, I think the idea of selecting the image nodes that nova speaks to is a great idea so by all means, keep investigating it but try to make it not nova specific.

[...]

Cheers,
Fla.


--
@flaper87
Flavio Percoco