You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Lakmal Warusawithana <la...@wso2.com> on 2013/07/11 10:49:40 UTC
LXC based Cartridges
Hi,
In the current Stratos, cartridge run time is a VM. With this if we want to
create a cartridge we have to do it for each and every IaaS that run
Stratos. So cartridge creator have to spend lot of time on this. And it
will be more costly when it comes to do a update of cartridges. We need to
have a way to create universal cartridges.
The best option what I see is we can use LXC as Cartridge run time. Then
when we create a LXC cartridge it will run on top of any IaaS, and only
need Linux VM. Also it give more benefit like we can pack many cartridge
runtime in single VM which give high utilization.
Here auto scaling going to happen in two levels and it’s coupled with smart
auto scaling policies, will discuss separate mail thread for what kind of
auto scaling polices need for Stratos.
Here I have drow some sample scenarios. Before going into detail we need
to get familiar with some terms
-
Partition
We can have partition for each cartridge type. For example we can have PHP
Partition, Tomcat Partition ..etc. Partition may consist of one or many VM
and this will come from policies. (will discuss in separate mail )
-
Subscription
User can subscribe to cartridge with some unique alias, say subscription A
-
Cartridge Process
Cartridge Processes are runtime environment (LXC) of subscribed cartridge.
For a one subscribed cartridge can have multiple Cartridge Processes
depending on auto scaling policies.
To accomplish this, Stratos Cloud Controller (CC) need to expand to support
LXC management. We need to have a cartridge store and it will store all
Cartridges (LXC based images). Then CC can spin out Partition VM depending
on policies associated with that cartridge type. A partition will have a CC
LXC agent and for the first time it will copy relevant Cartridge images.
When scaling request comes to CC it will communicate relevant Partition’s
LXC agent and agent who is responsible for spinning up LXCs (Cartridge
Processes).
So we need to implement this LXC agent (It should handle all LXC
management). I am looking some help from expert who in the Apache Stratos
community who may already worked on LXC. Maybe we can used existing open
source tools. Docker [1] is one I found while doing some research.
Please share your expertise on this then we can finalize how we can
implement this. We are in the process of organizing some google hangout
sessions to conduct some technical discussion of Stratos and we can discuss
this also in a hangout.
thanks
[1]https://github.com/dotcloud/docker
--
Lakmal Warusawithana
Software Architect; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: LXC based Cartridges
Posted by Lakmal Warusawithana <la...@wso2.com>.
On Thu, Jul 11, 2013 at 5:32 PM, bala ajanthan <ba...@gmail.com>wrote:
>
>
>
> On Thu, Jul 11, 2013 at 4:48 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
>
>>
>> Hi Ajanthan,
>>
>> On Thu, Jul 11, 2013 at 4:33 PM, bala ajanthan <ba...@gmail.com>wrote:
>>
>>> Hi devs,
>>> I am not a LXC expert but like to share some thoughts.
>>>
>>>
>>> On Thu, Jul 11, 2013 at 2:19 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> In the current Stratos, cartridge run time is a VM. With this if we
>>>> want to create a cartridge we have to do it for each and every IaaS that
>>>> run Stratos. So cartridge creator have to spend lot of time on this. And it
>>>> will be more costly when it comes to do a update of cartridges. We need to
>>>> have a way to create universal cartridges.
>>>>
>>> +1 for universal cartridges.But if the server (eg: wso2as) supports
>>> multi-tenancy already it is not good to spawn that server into some light
>>> weight container, rather we can spawn a vm(as it works in current model) or
>>> possibly LXC with more resource(we have to loose some i/o performance due
>>> to file system mounting). If the server is not multi-tenanted(eg:php) then
>>> we can spawn a container(lxc). This way we can optimize resource sharing
>>> and performance.
>>>
>>
>> Again we can set this with the policy. If we want to run one cartridge
>> process for VM, we can have in the policy.
>>
>>
>>>
>>>> The best option what I see is we can use LXC as Cartridge run time.
>>>> Then when we create a LXC cartridge it will run on top of any IaaS, and
>>>> only need Linux VM. Also it give more benefit like we can pack many
>>>> cartridge runtime in single VM which give high utilization.
>>>>
>>> Here if the implementation is abstracted(OS independent way) out such a
>>> way the container implementation is pluggable then we can run even .net
>>> cartridge also based on other implementation.
>>>
>>
>> AFAIK there are no such OS independent way to have cartridge process. For
>> windows based cartridge we can run one cartridge per VM based model.
>>
>>
>>>
>>>> Here auto scaling going to happen in two levels and it’s coupled with
>>>> smart auto scaling policies, will discuss separate mail thread for what
>>>> kind of auto scaling polices need for Stratos.
>>>>
>>>>
>>>>
>>>> Here I have drow some sample scenarios. Before going into detail we
>>>> need to get familiar with some terms
>>>>
>>>> -
>>>>
>>>> Partition
>>>>
>>>> We can have partition for each cartridge type. For example we can have
>>>> PHP Partition, Tomcat Partition ..etc. Partition may consist of one or many
>>>> VM and this will come from policies. (will discuss in separate mail )
>>>>
>>>> -
>>>>
>>>> Subscription
>>>>
>>>> User can subscribe to cartridge with some unique alias, say
>>>> subscription A
>>>>
>>>> -
>>>>
>>>> Cartridge Process
>>>>
>>>> Cartridge Processes are runtime environment (LXC) of subscribed
>>>> cartridge. For a one subscribed cartridge can have multiple Cartridge
>>>> Processes depending on auto scaling policies.
>>>>
>>>> To accomplish this, Stratos Cloud Controller (CC) need to expand to
>>>> support LXC management. We need to have a cartridge store and it will
>>>> store all Cartridges (LXC based images).
>>>>
>>> So here we need a image registry.possible candidate may be Openstack
>>> galance[0]. Docker has it own image registry[1].
>>>
>>
>> Yes we need to have a registry, but do not want to tie up with IaaS. It
>> should work for all IaaSs.
>>
> What i meant is using galance as a standalone registry for us not as
> service from IAAS.
>
+1, Ajanthan.
>
>>
>>> Then CC can spin out Partition VM depending on policies associated
>>>> with that cartridge type. A partition will have a CC LXC agent and for the
>>>> first time it will copy relevant Cartridge images. When scaling request
>>>> comes to CC it will communicate relevant Partition’s LXC agent and agent
>>>> who is responsible for spinning up LXCs (Cartridge Processes).
>>>>
>>> In addition to that the container can be showdown if there is no request
>>> for long time and we can start the container when there is a request.This
>>> way we can improve resource re-usage.We do not need to worry about the time
>>> to the first response hence the container boot up time is very minimal if
>>> we boot up the container(boot up a image snapshot. There is a way to save
>>> image like base image +changes using union file-system) without re
>>> initialize the cartridge.
>>>
>>
>> Yes it is another benefit that we can gain from LXC
>>
>>
>>>
>>>
>>>>
>>>> So we need to implement this LXC agent (It should handle all LXC
>>>> management). I am looking some help from expert who in the Apache Stratos
>>>> community who may already worked on LXC. Maybe we can used existing open
>>>> source tools. Docker [1] is one I found while doing some research.
>>>>
>>> Consider warden[2] also there they have abstracted out so that they were
>>> able to build a .net warden also[3].
>>>
>>
>> Thanks, will look into those.
>>
>>
>>>
>>>> Please share your expertise on this then we can finalize how we can
>>>> implement this. We are in the process of organizing some google hangout
>>>> sessions to conduct some technical discussion of Stratos and we can discuss
>>>> this also in a hangout.
>>>>
>>>>
>>>> thanks
>>>>
>>>> [1]https://github.com/dotcloud/docker
>>>>
>>>>
>>>> --
>>>> Lakmal Warusawithana
>>>> Software Architect; WSO2 Inc.
>>>> Mobile : +94714289692
>>>> Blog : http://lakmalsview.blogspot.com/
>>>>
>>>> [0]https://github.com/openstack/glance
>>> [1]https://github.com/dotcloud/docker-registry
>>> [2]https://github.com/cloudfoundry/warden/blob/master/warden/README.md
>>> [3]
>>> http://blog.ironfoundry.org/2013/07/deploy-net-apps-to-cloud-foundry-v2-with-iron-foundry/
>>>
>>> --
>>> Balachandiran Ajanthan
>>> Phone:+94775581497
>>> Blog : http://ajanthan87.blogspot.com
>>> Twitter: ajanthan87
>>> skype :bala.ajanthan
>>> gtalk :balaajanthan
>>>
>>
>>
>>
>> --
>> Lakmal Warusawithana
>> Software Architect; WSO2 Inc.
>> Mobile : +94714289692
>> Blog : http://lakmalsview.blogspot.com/
>>
>>
>
>
> --
> Balachandiran Ajanthan
> Phone:+94775581497
> Blog : http://ajanthan87.blogspot.com
> Twitter: ajanthan87
> skype :bala.ajanthan
> gtalk :balaajanthan
>
--
Lakmal Warusawithana
Software Architect; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: LXC based Cartridges
Posted by bala ajanthan <ba...@gmail.com>.
On Thu, Jul 11, 2013 at 4:48 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
>
> Hi Ajanthan,
>
> On Thu, Jul 11, 2013 at 4:33 PM, bala ajanthan <ba...@gmail.com>wrote:
>
>> Hi devs,
>> I am not a LXC expert but like to share some thoughts.
>>
>>
>> On Thu, Jul 11, 2013 at 2:19 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
>>
>>> Hi,
>>>
>>>
>>> In the current Stratos, cartridge run time is a VM. With this if we want
>>> to create a cartridge we have to do it for each and every IaaS that run
>>> Stratos. So cartridge creator have to spend lot of time on this. And it
>>> will be more costly when it comes to do a update of cartridges. We need to
>>> have a way to create universal cartridges.
>>>
>> +1 for universal cartridges.But if the server (eg: wso2as) supports
>> multi-tenancy already it is not good to spawn that server into some light
>> weight container, rather we can spawn a vm(as it works in current model) or
>> possibly LXC with more resource(we have to loose some i/o performance due
>> to file system mounting). If the server is not multi-tenanted(eg:php) then
>> we can spawn a container(lxc). This way we can optimize resource sharing
>> and performance.
>>
>
> Again we can set this with the policy. If we want to run one cartridge
> process for VM, we can have in the policy.
>
>
>>
>>> The best option what I see is we can use LXC as Cartridge run time.
>>> Then when we create a LXC cartridge it will run on top of any IaaS, and
>>> only need Linux VM. Also it give more benefit like we can pack many
>>> cartridge runtime in single VM which give high utilization.
>>>
>> Here if the implementation is abstracted(OS independent way) out such a
>> way the container implementation is pluggable then we can run even .net
>> cartridge also based on other implementation.
>>
>
> AFAIK there are no such OS independent way to have cartridge process. For
> windows based cartridge we can run one cartridge per VM based model.
>
>
>>
>>> Here auto scaling going to happen in two levels and it’s coupled with
>>> smart auto scaling policies, will discuss separate mail thread for what
>>> kind of auto scaling polices need for Stratos.
>>>
>>>
>>>
>>> Here I have drow some sample scenarios. Before going into detail we
>>> need to get familiar with some terms
>>>
>>> -
>>>
>>> Partition
>>>
>>> We can have partition for each cartridge type. For example we can have
>>> PHP Partition, Tomcat Partition ..etc. Partition may consist of one or many
>>> VM and this will come from policies. (will discuss in separate mail )
>>>
>>> -
>>>
>>> Subscription
>>>
>>> User can subscribe to cartridge with some unique alias, say subscription
>>> A
>>>
>>> -
>>>
>>> Cartridge Process
>>>
>>> Cartridge Processes are runtime environment (LXC) of subscribed
>>> cartridge. For a one subscribed cartridge can have multiple Cartridge
>>> Processes depending on auto scaling policies.
>>>
>>> To accomplish this, Stratos Cloud Controller (CC) need to expand to
>>> support LXC management. We need to have a cartridge store and it will
>>> store all Cartridges (LXC based images).
>>>
>> So here we need a image registry.possible candidate may be Openstack
>> galance[0]. Docker has it own image registry[1].
>>
>
> Yes we need to have a registry, but do not want to tie up with IaaS. It
> should work for all IaaSs.
>
What i meant is using galance as a standalone registry for us not as
service from IAAS.
>
>
>> Then CC can spin out Partition VM depending on policies associated with
>>> that cartridge type. A partition will have a CC LXC agent and for the first
>>> time it will copy relevant Cartridge images. When scaling request comes to
>>> CC it will communicate relevant Partition’s LXC agent and agent who is
>>> responsible for spinning up LXCs (Cartridge Processes).
>>>
>> In addition to that the container can be showdown if there is no request
>> for long time and we can start the container when there is a request.This
>> way we can improve resource re-usage.We do not need to worry about the time
>> to the first response hence the container boot up time is very minimal if
>> we boot up the container(boot up a image snapshot. There is a way to save
>> image like base image +changes using union file-system) without re
>> initialize the cartridge.
>>
>
> Yes it is another benefit that we can gain from LXC
>
>
>>
>>
>>>
>>> So we need to implement this LXC agent (It should handle all LXC
>>> management). I am looking some help from expert who in the Apache Stratos
>>> community who may already worked on LXC. Maybe we can used existing open
>>> source tools. Docker [1] is one I found while doing some research.
>>>
>> Consider warden[2] also there they have abstracted out so that they were
>> able to build a .net warden also[3].
>>
>
> Thanks, will look into those.
>
>
>>
>>> Please share your expertise on this then we can finalize how we can
>>> implement this. We are in the process of organizing some google hangout
>>> sessions to conduct some technical discussion of Stratos and we can discuss
>>> this also in a hangout.
>>>
>>>
>>> thanks
>>>
>>> [1]https://github.com/dotcloud/docker
>>>
>>>
>>> --
>>> Lakmal Warusawithana
>>> Software Architect; WSO2 Inc.
>>> Mobile : +94714289692
>>> Blog : http://lakmalsview.blogspot.com/
>>>
>>> [0]https://github.com/openstack/glance
>> [1]https://github.com/dotcloud/docker-registry
>> [2]https://github.com/cloudfoundry/warden/blob/master/warden/README.md
>> [3]
>> http://blog.ironfoundry.org/2013/07/deploy-net-apps-to-cloud-foundry-v2-with-iron-foundry/
>>
>> --
>> Balachandiran Ajanthan
>> Phone:+94775581497
>> Blog : http://ajanthan87.blogspot.com
>> Twitter: ajanthan87
>> skype :bala.ajanthan
>> gtalk :balaajanthan
>>
>
>
>
> --
> Lakmal Warusawithana
> Software Architect; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
>
--
Balachandiran Ajanthan
Phone:+94775581497
Blog : http://ajanthan87.blogspot.com
Twitter: ajanthan87
skype :bala.ajanthan
gtalk :balaajanthan
Re: LXC based Cartridges
Posted by Lakmal Warusawithana <la...@wso2.com>.
Hi Ajanthan,
On Thu, Jul 11, 2013 at 4:33 PM, bala ajanthan <ba...@gmail.com>wrote:
> Hi devs,
> I am not a LXC expert but like to share some thoughts.
>
>
> On Thu, Jul 11, 2013 at 2:19 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
>
>> Hi,
>>
>>
>> In the current Stratos, cartridge run time is a VM. With this if we want
>> to create a cartridge we have to do it for each and every IaaS that run
>> Stratos. So cartridge creator have to spend lot of time on this. And it
>> will be more costly when it comes to do a update of cartridges. We need to
>> have a way to create universal cartridges.
>>
> +1 for universal cartridges.But if the server (eg: wso2as) supports
> multi-tenancy already it is not good to spawn that server into some light
> weight container, rather we can spawn a vm(as it works in current model) or
> possibly LXC with more resource(we have to loose some i/o performance due
> to file system mounting). If the server is not multi-tenanted(eg:php) then
> we can spawn a container(lxc). This way we can optimize resource sharing
> and performance.
>
Again we can set this with the policy. If we want to run one cartridge
process for VM, we can have in the policy.
>
>> The best option what I see is we can use LXC as Cartridge run time. Then
>> when we create a LXC cartridge it will run on top of any IaaS, and only
>> need Linux VM. Also it give more benefit like we can pack many cartridge
>> runtime in single VM which give high utilization.
>>
> Here if the implementation is abstracted(OS independent way) out such a
> way the container implementation is pluggable then we can run even .net
> cartridge also based on other implementation.
>
AFAIK there are no such OS independent way to have cartridge process. For
windows based cartridge we can run one cartridge per VM based model.
>
>> Here auto scaling going to happen in two levels and it’s coupled with
>> smart auto scaling policies, will discuss separate mail thread for what
>> kind of auto scaling polices need for Stratos.
>>
>>
>>
>> Here I have drow some sample scenarios. Before going into detail we need
>> to get familiar with some terms
>>
>> -
>>
>> Partition
>>
>> We can have partition for each cartridge type. For example we can have
>> PHP Partition, Tomcat Partition ..etc. Partition may consist of one or many
>> VM and this will come from policies. (will discuss in separate mail )
>>
>> -
>>
>> Subscription
>>
>> User can subscribe to cartridge with some unique alias, say subscription A
>>
>> -
>>
>> Cartridge Process
>>
>> Cartridge Processes are runtime environment (LXC) of subscribed
>> cartridge. For a one subscribed cartridge can have multiple Cartridge
>> Processes depending on auto scaling policies.
>>
>> To accomplish this, Stratos Cloud Controller (CC) need to expand to
>> support LXC management. We need to have a cartridge store and it will
>> store all Cartridges (LXC based images).
>>
> So here we need a image registry.possible candidate may be Openstack
> galance[0]. Docker has it own image registry[1].
>
Yes we need to have a registry, but do not want to tie up with IaaS. It
should work for all IaaSs.
> Then CC can spin out Partition VM depending on policies associated with
>> that cartridge type. A partition will have a CC LXC agent and for the first
>> time it will copy relevant Cartridge images. When scaling request comes to
>> CC it will communicate relevant Partition’s LXC agent and agent who is
>> responsible for spinning up LXCs (Cartridge Processes).
>>
> In addition to that the container can be showdown if there is no request
> for long time and we can start the container when there is a request.This
> way we can improve resource re-usage.We do not need to worry about the time
> to the first response hence the container boot up time is very minimal if
> we boot up the container(boot up a image snapshot. There is a way to save
> image like base image +changes using union file-system) without re
> initialize the cartridge.
>
Yes it is another benefit that we can gain from LXC
>
>
>>
>> So we need to implement this LXC agent (It should handle all LXC
>> management). I am looking some help from expert who in the Apache Stratos
>> community who may already worked on LXC. Maybe we can used existing open
>> source tools. Docker [1] is one I found while doing some research.
>>
> Consider warden[2] also there they have abstracted out so that they were
> able to build a .net warden also[3].
>
Thanks, will look into those.
>
>> Please share your expertise on this then we can finalize how we can
>> implement this. We are in the process of organizing some google hangout
>> sessions to conduct some technical discussion of Stratos and we can discuss
>> this also in a hangout.
>>
>>
>> thanks
>>
>> [1]https://github.com/dotcloud/docker
>>
>>
>> --
>> Lakmal Warusawithana
>> Software Architect; WSO2 Inc.
>> Mobile : +94714289692
>> Blog : http://lakmalsview.blogspot.com/
>>
>> [0]https://github.com/openstack/glance
> [1]https://github.com/dotcloud/docker-registry
> [2]https://github.com/cloudfoundry/warden/blob/master/warden/README.md
> [3]
> http://blog.ironfoundry.org/2013/07/deploy-net-apps-to-cloud-foundry-v2-with-iron-foundry/
>
> --
> Balachandiran Ajanthan
> Phone:+94775581497
> Blog : http://ajanthan87.blogspot.com
> Twitter: ajanthan87
> skype :bala.ajanthan
> gtalk :balaajanthan
>
--
Lakmal Warusawithana
Software Architect; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: LXC based Cartridges
Posted by bala ajanthan <ba...@gmail.com>.
Hi devs,
I am not a LXC expert but like to share some thoughts.
On Thu, Jul 11, 2013 at 2:19 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
> Hi,
>
>
> In the current Stratos, cartridge run time is a VM. With this if we want
> to create a cartridge we have to do it for each and every IaaS that run
> Stratos. So cartridge creator have to spend lot of time on this. And it
> will be more costly when it comes to do a update of cartridges. We need to
> have a way to create universal cartridges.
>
+1 for universal cartridges.But if the server (eg: wso2as) supports
multi-tenancy already it is not good to spawn that server into some light
weight container, rather we can spawn a vm(as it works in current model) or
possibly LXC with more resource(we have to loose some i/o performance due
to file system mounting). If the server is not multi-tenanted(eg:php) then
we can spawn a container(lxc). This way we can optimize resource sharing
and performance.
>
> The best option what I see is we can use LXC as Cartridge run time. Then
> when we create a LXC cartridge it will run on top of any IaaS, and only
> need Linux VM. Also it give more benefit like we can pack many cartridge
> runtime in single VM which give high utilization.
>
Here if the implementation is abstracted(OS independent way) out such a way
the container implementation is pluggable then we can run even .net
cartridge also based on other implementation.
>
> Here auto scaling going to happen in two levels and it’s coupled with
> smart auto scaling policies, will discuss separate mail thread for what
> kind of auto scaling polices need for Stratos.
>
>
>
> Here I have drow some sample scenarios. Before going into detail we need
> to get familiar with some terms
>
> -
>
> Partition
>
> We can have partition for each cartridge type. For example we can have PHP
> Partition, Tomcat Partition ..etc. Partition may consist of one or many VM
> and this will come from policies. (will discuss in separate mail )
>
> -
>
> Subscription
>
> User can subscribe to cartridge with some unique alias, say subscription A
>
> -
>
> Cartridge Process
>
> Cartridge Processes are runtime environment (LXC) of subscribed cartridge.
> For a one subscribed cartridge can have multiple Cartridge Processes
> depending on auto scaling policies.
>
> To accomplish this, Stratos Cloud Controller (CC) need to expand to
> support LXC management. We need to have a cartridge store and it will
> store all Cartridges (LXC based images).
>
So here we need a image registry.possible candidate may be Openstack
galance[0]. Docker has it own image registry[1].
> Then CC can spin out Partition VM depending on policies associated with
> that cartridge type. A partition will have a CC LXC agent and for the first
> time it will copy relevant Cartridge images. When scaling request comes to
> CC it will communicate relevant Partition’s LXC agent and agent who is
> responsible for spinning up LXCs (Cartridge Processes).
>
In addition to that the container can be showdown if there is no request
for long time and we can start the container when there is a request.This
way we can improve resource re-usage.We do not need to worry about the time
to the first response hence the container boot up time is very minimal if
we boot up the container(boot up a image snapshot. There is a way to save
image like base image +changes using union file-system) without re
initialize the cartridge.
>
> So we need to implement this LXC agent (It should handle all LXC
> management). I am looking some help from expert who in the Apache Stratos
> community who may already worked on LXC. Maybe we can used existing open
> source tools. Docker [1] is one I found while doing some research.
>
Consider warden[2] also there they have abstracted out so that they were
able to build a .net warden also[3].
>
> Please share your expertise on this then we can finalize how we can
> implement this. We are in the process of organizing some google hangout
> sessions to conduct some technical discussion of Stratos and we can discuss
> this also in a hangout.
>
>
> thanks
>
> [1]https://github.com/dotcloud/docker
>
>
> --
> Lakmal Warusawithana
> Software Architect; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
> [0]https://github.com/openstack/glance
[1]https://github.com/dotcloud/docker-registry
[2]https://github.com/cloudfoundry/warden/blob/master/warden/README.md
[3]
http://blog.ironfoundry.org/2013/07/deploy-net-apps-to-cloud-foundry-v2-with-iron-foundry/
--
Balachandiran Ajanthan
Phone:+94775581497
Blog : http://ajanthan87.blogspot.com
Twitter: ajanthan87
skype :bala.ajanthan
gtalk :balaajanthan