Hi, Zhiyuan, Good idea. I am also trying to find whether there are other values could be added by a new bottom cascade service.
And the most negative part of a bottom cascade service is that it’ll impact the openstack distribution and deployment. Best Regards Chaoyi Huang ( Joe Huang ) From: Vega Cai [mailto:luckyveg...@gmail.com] Sent: Monday, August 03, 2015 3:17 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [tricircle] local pluggable cascaded service Agree that we use polling mode to synchronize resource status, but it's a bit weird to deploy a localized service for just polling. Maybe we can define a status synchronizatioin task to handle such work so it can be done by cascade service itself. If multiple cascade service is deployed, to avoid conflict, we can utilize leader selection (provided by zookeeper and other tools) to find a leader cascade service. Leader cascade service is responsible for periodically creating status synchronization task and other members finish the task. BR Zhiyuan On 3 August 2015 at 14:48, joehuang <joehu...@huawei.com<mailto:joehu...@huawei.com>> wrote: Hi, In the PoC, the status synchronization is done by the proxy node running with periodic task to poll the recent changed status, for example, VM status, volume status, and port status, etc. One proxy node will be responsible for one cascaded OpenStack instance, and configured with one user to be able to query the status. It works, although not perfect, and the controllable. During the last weekly meeting, Gampel mentioned that to have a local pluggable cascaded service for "port status" and other site-localized information collection, and push to the top layer cascade service. I would like to know more your thoughts on the “push” method. 1. We cannot push every status change to the top layer, especially if one site’s down and restart all service, then all object’s status will be changed frequently in very short time, if “push” based on every status, imaging that there are lots of objects in one site, the burst API calling to the top layer will be un-controllable. 2. The local cascaded service has to listen on the message bus to track each status change event of all objects. It’ll work like Ceilometers agent to capture the status change events. Not all status change will send notification even to the message bus, have to add code to each service. It’s also complex to implement. To my understanding, the more viable way is to deploy a localized service, but still using polling method to get the status, and send to the up layer in batch mode to reduce the number of API calling to the top layer. In the top layer, using a task to process the status change in case of burst status refresh. Best Regards Chaoyi Huang ( joehuang ) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
