Open Stack

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> 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://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/20150803/83f23421/attachment.html>