On Wednesday, February 18, 2015, Rajkumar Rajaratnam <rajkum...@wso2.com> wrote:
> Hi Imesh, > > Please find a question inline. > > On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <im...@apache.org > <javascript:_e(%7B%7D,'cvml','im...@apache.org');>> wrote: > >> Hi Devs, >> >> Today we had a call on this topic and please find the summary of the >> discussion below: >> >> - In Stratos 4.0.0 the deployment policy was defined in the global >> context and it was reusable. >> - Now deployment policy is in application context and contains deployment >> pattens of multiple cartridges. >> - As a result the application deployment process has become complex and >> backward compatibility with the previous release has been broken. >> >> - Therefore we can do a slight modification in the current model and move >> the deployment policy to the global context: >> - If so we will have following entities in the global context: >> >> >> - Then we can construct the application by referring Cartridges, >> Cartridge Groups, Autoscaling Policies and Deployment Policies: >> - Either Cartridges or Cartridge Groups can refer Deployment Policies: >> >> >> >> > Why a cartridge group need to refer a deployment policy? I assume if a > cartridge group is referring a deployment policy, then all the cartridges > under that group will use the same deployment policy referred by the group? > Or this is for something else. Please give me some insight on this. > Yes you are correct. Cartridges under a group will use same department policy referred by the group. > Thanks. > > >> - Now we need to provide an application policy at the application >> deployment time to specify application availability in network partitions: >> - This would say whether to start the application in all network >> partitions or do cloud bursting: >> >> >> - At a later release we can introduce Application Template concept by >> extracting subscribable information out from the application: >> >> >> >> Please add your thoughts on this modification. >> >> Thanks >> >> >> On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <im...@apache.org >> <javascript:_e(%7B%7D,'cvml','im...@apache.org');>> wrote: >> >>> +1 for the idea Lakmal! Yes I think it is better to have a call and >>> discuss this before doing any changes. >>> >>> Thanks >>> >>> On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <lak...@wso2.com >>> <javascript:_e(%7B%7D,'cvml','lak...@wso2.com');>> wrote: >>> >>>> Hi Shaheed, >>>> >>>> Will try to explain further but simple and here some workaround >>>> solution. >>>> >>>> Previous release we only subscribe to a single cartridge with given >>>> deployment policy. We have re used defined deployment policy. The main >>>> reason that we cloud do, single cartridge has single deployment patten for >>>> a particular deployment. >>>> >>>> If we come to composite application with multiple cartridges we have to >>>> define deployment pattens for each and every cartridge in that composite >>>> application. Defining deployment patten, have to use cartridge alias for >>>> distinguish deferent cartridges because we can't use cartridge type, some >>>> application may have multiple same cartridges and need different deployment >>>> pattens. >>>> >>>> To address particular in your scenario, we can't have two >>>> implementation whether is singleton or a composite group. Here one possible >>>> solution, I believe we can implement, and which will cover your simple >>>> scenario as well. >>>> >>>> solution : >>>> >>>> - shall we allow to have global deployment policies (can have many) >>>> which can pre deploy/add. (I will explain what is these global one) >>>> - and will allow, in the defining the deployment policy time to >>>> attached above without defining. (user has both option) >>>> - then deploy the application >>>> >>>> I believed this is what you are looking for >>>> >>>> Let me explain these global deployment policy concept. We have section >>>> call childPolicies which we refer different cartridge alias to define >>>> deployment pattens. >>>> >>>> "childPolicies": [ >>>> >>>> { >>>> >>>> "alias": "mytomcat", >>>> >>>> "networkPartition": [ >>>> >>>> { >>>> >>>> "id": "network-partition-1", >>>> >>>> "partitionAlgo": "one-after-another", >>>> >>>> "partitions": [ >>>> >>>> { >>>> >>>> "id": "partition-1", >>>> >>>> "max": 5 >>>> >>>> } >>>> >>>> ] >>>> >>>> } >>>> >>>> ] >>>> >>>> } >>>> >>>> I like to propose, introduce section call globalPolicies which can >>>> define global deployment pattens which going to apply for all cartridges >>>> defining in that application. If it is single cartridge or not it will use >>>> same deployment patten. >>>> >>>> With this implementation, without changing current design and >>>> implementation we can achieved simple singleton scenario with attaching >>>> same deployment policies without re defining per application >>>> creation/deploy. >>>> >>>> Please share your thoughts >>>> >>>> >>>> >>>> On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org >>>> <javascript:_e(%7B%7D,'cvml','im...@apache.org');>> wrote: >>>> >>>>> Yes, I agree with your concerns Shaheed! Please find my comments below: >>>>> >>>>> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <shahh...@cisco.com >>>>> <javascript:_e(%7B%7D,'cvml','shahh...@cisco.com');>> wrote: >>>>> >>>>>> >>>>>> >>>>>> OK, I get that argument. But consider that multiple subscriptions all >>>>>> using a single deployment spec was the previous model, and now we have >>>>>> inverted that cardinality completely. >>>>>> >>>>> >>>>>> >>>>> Not exactly, we support multiple subscriptions for Multi-Tenant >>>>> applications but not for Single-Tenant applications. This is again due to >>>>> the reason I have explained in the previous response. May be we can >>>>> improve >>>>> this in a minor release. BTW the term Subscription has now being changed >>>>> to >>>>> Application SignUp. >>>>> >>>>>> >>>>>> >>>>> To my knowledge, in addition to the generic automation of single >>>>>> cartridge subscriptions we provided our Stratos users, at least two users >>>>>> have significant investment in dynamically generating and >>>>>> subscribing/unsubscribing cartridges on-the-fly. Converting these to use >>>>>> single application cartridges is necessary work needed to get to 4.1, but >>>>>> all these usages will now require substantive rework to manage the >>>>>> opposite >>>>>> cardinality w.r.t. deployment policies. >>>>>> >>>>> >>>>>> >>>>> Here we deploy an application in the context of Tenant not for User. >>>>> Yes in this release it is not possible to share Single-Tenant applications >>>>> accross tenants. However each tenant can deploy the same application with >>>>> a >>>>> different deployment policy by using a different application id. >>>>> >>>>> >>>>>> I'm all in favour of progress, and change where unavoidable, but this >>>>>> seems to gratuitously change the model for the bulk of singleton >>>>>> cartridge >>>>>> users in favour of the currently non-existent grouping users. (And yes, I >>>>>> am aware of the paradox that we are VERY interested in the grouping). >>>>>> >>>>> >>>>> Yes I agree, may be we can have a separate discussion on this and >>>>> propose improvements for the next minor release. >>>>> >>>>> Thanks >>>>> >>>> >>>> >>>> >>>> -- >>>> Lakmal Warusawithana >>>> Vice President, Apache Stratos >>>> Director - Cloud Architecture; WSO2 Inc. >>>> Mobile : +94714289692 >>>> Blog : http://lakmalsview.blogspot.com/ >>>> >>>> >>> >>> >>> -- >>> Imesh Gunaratne >>> >>> Technical Lead, WSO2 >>> Committer & PMC Member, Apache Stratos >>> >> >> >> >> -- >> Imesh Gunaratne >> >> Technical Lead, WSO2 >> Committer & PMC Member, Apache Stratos >> > > > > -- > Rajkumar Rajaratnam > Committer & PMC Member, Apache Stratos > Software Engineer, WSO2 > > Mobile : +94777568639 > Blog : rajkumarr.com > -- Sent from Gmail Mobile