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 (aik...@mxk.nes.nec.co.jp) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-- @flaper87 Flavio Percoco
pgpaxQeDoq4aT.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
