Fwd: Re: Relicensing XS Java bindings for CloudStack

2012-08-19 Thread Ewan Mellor
The XenServer team have re-licensed their SDK as promised.  Links are below. We 
can import this directly as a CloudStack dependency now.

Ewan.

[1] http://community.citrix.com/display/xs/XenServer+SDK+Archive
[2]
http://community.citrix.com/download/attachments/38633496/XenServerJava-5.6.100-2.zip?version=1
[3]
http://community.citrix.com/download/attachments/38633496/XenServerJava-5.6.100-2-src.zip?version=1



Re: [Discuss] CloudStack architecture to a loosely-coupled component oriented distributed architecture

2012-08-19 Thread Murali Reddy
On 16/08/12 11:27 PM, "Kelven Yang"  wrote:

>
>On 8/15/12 10:57 PM, "Alex Huang"  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?




[Add plugin to CS]

2012-08-19 Thread Nguyen Anh Tu
Hi,

I want to ask about steps to add a new plugin to CS. I found that plugin is
easy way to add new feature / function to my own cloudstack. For testing, I
write a new class name: LastFit.java, which extend the HostAllocator
interface. Then I pack to JAR file and define it in components.xml. I
follow the guide "CloudStack2.2AllocatorImplementationGuide", but CS
doesn't realize the new package. I saw to CS 4.0 source code and found that
it's a new structure. So I wonder that how I can add a plugin to CS ver 4.0
(or maybe 3.0.5).

Any help?
Thank so much.

-- 

N.g.U.y.e.N.A.n.H.t.U