On Thu, Jul 11, 2013 at 4:48 PM, Lakmal Warusawithana <[email protected]>wrote:
> > Hi Ajanthan, > > On Thu, Jul 11, 2013 at 4:33 PM, bala ajanthan <[email protected]>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 <[email protected]>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
