Open Stack

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:luckyvega.g at 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 <joehuang at huawei.com<mailto:joehuang at 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-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150807/6cc8a2ab/attachment.html>