Open Stack

On 03/02/14 06:09 +0000, Eiichi Aikawa wrote:
>Hi,
>
>Here is the blueprint about improvement of accessing to glance API server.
>  https://blueprints.launchpad.net/nova/+spec/improvement-of-accessing-to-glance
>
>The summary of this bp is:
> - Glance API Servers are categorized into two groups: "Primary" and "Secondary".
> - Firstly, Nova tries to access Glance API Servers of "Primary" randomly.
> - If failed to access all "Primary" Servers, Nova tries to access "Secondary"
>   Servers randomly.
>
>We suppose the near servers will be treated as "Primary", and other servers
>as "Secondary".
>
>The benefits of this bp we think is as followings.
> - 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, accessing glance API server
>   in the same chassis can make efficiency better than using in other chassis.
>
>This can reduce the network traffic and increase the efficiency.
>

I went through the blueprint and the review. I've to say that I agree
with Russell. I don't think making nova's config more complex is the
way to go.

I've more comments, though.

Glance doesn't have a "Primary" / "Secondary" concept and I don't
think it makes a lot of sense to add it. You could easily specify the
nearest glance node and fallback to the service catalog if the
glance-api node is not available anymore. Even better would be to
always rely on the service catalog.

That said, it seems that the goal of this blueprint is also similar to
the work happening here[0] - or at least it could be achieved as part
of that.

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.

One last comment, `glance_api_server` is, usually, the address of a
load balancer that sits on top of several glance-api nodes. I'm pretty
sure this kind of node selection can be also optimized in services
like haproxy.

Summary, I don't think the proposed solution in this blueprint is the
way to go. I do think node selection is important but I'd focus more
on the nearest store selection rather than the glance-api node
selection for now. The work on the multiple-location support blueprint
for nova is promising.

Cheers,
flaper

[0] https://review.openstack.org/#/c/33409/
>Please give us your advice/comment.
>
>Regards,
>E.Aikawa (aikawa at mxk.nes.nec.co.jp)
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140203/32b50762/attachment.pgp>