incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kelven Yang <>
Subject Re: [Discuss] CloudStack architecture to a loosely-coupled component oriented distributed architecture
Date Tue, 21 Aug 2012 05:24:42 GMT

On 8/20/12 9:49 PM, "Kelven Yang" <> wrote:

>On 8/20/12 9:33 PM, "Murali Reddy" <> wrote:
>>On 20/08/12 11:23 PM, "Kelven Yang" <> wrote:
>>>The key point is the shifting to event-driven programming model itself
>>>orchestration layer, the underlying facility is currently not at
>>>path, we will need to do a messaging arbitration here so that we can
>>>plugin a suitable MQ selection in a fairly easy step. One thing I'm sure
>>>is that we won't use two separated MQ solutions in one system.
>>Agree. Underlaying messaging infrastructure is not much of concern,

>>but my
>>point was we need to have message abstraction (be it for IPC, event
>>notifications) requirements so that we know what to expect from
>>when we need to choose.

I just started to work on this. I'm evaluating and testing out the
messaging choice (ZeroMQ/ActiveMQ) in javelin branch. Here is some of
requirements I'm considering

Event notification for orchestration signaling process
RPC over message queue

Above two use the queue facility as a unicast and multicast capable
transport, reliable delivery is not mandatory, and persistency is also not
mandatory, but responding time should be in range of orchestration needs.
I original thought to use blind-multicast to auto-scale the event
processing components, however, this approach needs assistant from a
distributed lock facility like ZooKeeper, now I'm also thinking to build
on top of a load balancing feature in the signaling process by using
multicast/unicast service provided from the messaging facility, basically,
event signaling process has a destination resolution phase before final
delivery and load balancing can be handled in the signaling phase without
a need for locking facility. (Maybe too complex and wild idea? This is
trying to reduce the setup complexity of the Cloud as a whole)

Persist queue events
This usually requires persistence and reliable queue service. Suitable for
workflow integration with external system (Murali's proposal)

>>>We also need to think twice of tight-coupled listener pattern across
>>>components, if listeners from different components are implicitly
>>>to participate application level transaction across components, it
>>>better be done through an orchestration process.
>>IMO, I think we need to move away from listener-callback paradigm in
>>distributed environment.
>This is exactly what I meant.
>>Good thing is its not used much and is not
>>required for event notification framework as well. Its good if we have
>>request-response messaging pattern. I am thinking aloud, in enterprise
>>environments it can enable 3rd party components to integrate workflows in
>>orchestrations in a loosely coupled manner. For e.g. On Vm starting event
>>message, external workflow software can provision resources like IP,
>>user creds etc provide a response which can be used to provision the Vm
>>with provided details.

View raw message