Sent from my iPhone
On Aug 19, 2012, at 10:29 PM, "Murali Reddy" <murali.re...@citrix.com> wrote: > On 16/08/12 11:27 PM, "Kelven Yang" <kelven.y...@citrix.com> wrote: > >> >> On 8/15/12 10:57 PM, "Alex Huang" <alex.hu...@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. >
