cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <Edison...@citrix.com>
Subject Re: [Discuss] CloudStack architecture to a loosely-coupled component oriented distributed architecture
Date Mon, 20 Aug 2012 07:31:10 GMT


Sent from my iPhone

On Aug 19, 2012, at 10:29 PM, "Murali Reddy" <Murali.Reddy@citrix.com> wrote:

> On 16/08/12 11:27 PM, "Kelven Yang" <kelven.yang@citrix.com> wrote:
> 
>> 
>> On 8/15/12 10:57 PM, "Alex Huang" <Alex.Huang@citrix.com> wrote:
>> 
>> 
>>> 
>>> I don't think Murali and Kelven's proposals are related.  Murali's is a
>>> notification system so that someone who doesn't even want to know about
>>> cloudstack's code can still interface with cloudstack and react to entity
>>> changes.  Kelven's defines the ipc mechanism used by cloudstack
>>> components.  I think it's best for these two to grow separately.  Now
>>> it's possible that the underlying mechanism to implement these two ends
>>> up to be the same thing but at least their semantics should be different.
>>> 
>>> --Alex
>>> 
>> 
>> 
>> As alex pointed, there are some differences between the two. I know that
>> in our current code base we use a lot of in-process listener-callback
>> pattern to encapsulate isolated logic in different modules for better
>> modularization. Inside the same component, this pattern applies perfectly.
>> However, when we come to a distributed world, unless the logic semantic
>> implies that this can be decoupled in disconnected fashion, we should not
>> use the listener-callback patter across components, it assumes strong
>> coupling, if the business logic requires such strong semantics, it should
>> go through in orchestration process so that the flow state can be managed
>> in terms of component failures.
>> 
>> Kelven
>> 
> 
> I do agree that what I am trying to do it an 'event notification system'
> by which components external to CloudStack gets a push notification of a
> resource state change in CloudStack, and the 'message event' proposed by
> Kelven is more of IPC mechanism for CloudStack components to interact in
> distributed architecture. But there are areas which seems to overlap
> significantly which needs to be discussed.
> 
> Kelven, can you please elaborate a bit on 'message event' in your proposal
> which seems to main IPC between the components? I am planning to introduce
> a state machine with every virtual/physical resource that CloudStack
> manages and generate events on the state change where subscribers are
> external components. If your plan is to have an event-driven architecture
> where orchestration engine and network/storage/compute components perform
> a work flow with exchange of resource state change (or required state
> change events) then same MOM (message oriented middleware) and pub-sub
> semantics can be shared except for the topic/channel will differ. If your
> plan is IPC to be message oriented or RPC over message queue semantics
> then at least that MOM is a common infrastructure piece on which both IPC
> and pub/sub event notifications can be built. Let me know your thoughts on
> these.
> 
> Redis, seems to be good messaging middleware, but is it in-memory? can it
> scale and run as cluster? How does it weigh againest AMQP as MOM
> middleware for CloudStack?
> 

http://www.cloudscaling.com/blog/cloud-computing/simplicity-scales-an-alternative-approach-to-openstack-nova-rpc-messaging/

Zeromq seems good.
> 

Mime
View raw message