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: - 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> wrote: >> >>> Yes, I agree with your concerns Shaheed! Please find my comments below: >>> >>> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <[email protected]> >>> 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
