Hi Isuru, Thanks for the quick response.
>However, as we go along we might find that we don't need everything in the proposal/ there additional functionality required. May be not in this document but IMO the complete Composite Application Model should be there in the documentation. Thanks On Fri, Jul 4, 2014 at 11:29 PM, Isuru Haththotuwa <isu...@apache.org> wrote: > Hi Imesh, > > > On Fri, Jul 4, 2014 at 7:46 PM, Imesh Gunaratne <im...@apache.org> wrote: > >> [Added Sanjiva to the list] >> >> Hi All, >> >> IMO this composite application model is really important for the future >> of Stratos and it will become the foundation for all other features. >> Therefore we need to make sure that it is simple, easy to understand, >> covers all currently available requirements and easy to extend. At some >> point we might need to add extensions to support well known similar >> specifications such as CAMP, CloudML and TOSCA. >> >> At present I do not see much feedback from the community on this. Shall >> we walk through this and suggest refinements? I had some concerns and added >> them to the below document [1]. @IsuruH: Is the document up to date? >> > This document is the initial proposal. It is a good starting point IMHO, > and covers the basic requirements for Service Grouping. However, as we go > along we might find that we don't need everything in the proposal/ there > additional functionality required. IMHO we can move forward with the > implementation, keeping the design open for extension to cater any future > requirements, as you have mentioned as well. > >> >> [1] >> https://docs.google.com/a/wso2.com/document/d/1qnArxF8obhbjMLUbPAENQMn94fPSd3AVqO41mxhnJXE/edit# >> >> Thanks >> >> >> On Thu, Jul 3, 2014 at 12:22 PM, Isuru Haththotuwa <isu...@apache.org> >> wrote: >> >>> For the initial implementation for persisting Service Group Definitions, >>> the functionality will cover: >>> >>> 1. Nested Service Groups >>> 2. Validation of the availability of referred Service Groups and >>> Cartridges >>> >>> I have copy-pasted two sample Service Group definitions [1, 2] below. >>> [2] is a nested group. >>> [1]. >>> { >>> "name": "group1", >>> "cartridges": [ >>> "mysql", "mongoDB" >>> ], >>> "dependencies": { >>> "killBehaviour": "kill-none" >>> } >>> } >>> >>> [2]. >>> { >>> "name": "group2", >>> "subGroups": [ >>> "group1" >>> ], >>> "cartridges": [ >>> "php" >>> ], >>> "dependencies": { >>> "startupOrder": [ >>> { >>> "start": "group.group1", >>> "after": "cartridge.php" >>> } >>> ], >>> "killBehaviour": "kill-dependents" >>> >>> } >>> } >>> >>> >>> >>> >>> On Mon, Jun 2, 2014 at 10:52 AM, Isuru Haththotuwa <isu...@apache.org> >>> wrote: >>> >>>> Hi Devs, >>>> >>>> This is an addition to the discussion happened in the thread [1]. I >>>> have included a very basic sequence diagram to show the flow of how Service >>>> Grouping would happen for the initial implementation. >>>> >>>> >>>> composite_app_1.png >>>> <https://docs.google.com/a/wso2.com/file/d/0B4pCC9A49FwCRDhqQ0JDRl9tQjA/edit?usp=drive_web> >>>> >>>> Short description of the flow:. >>>> >>>> 1, 2 & 3. Deploy Components' Definitions that would be included in the >>>> top level Composite Application. Typically, a component would map to a >>>> single cartridge. For sample JSON definitions of a component, please refer >>>> [1]. >>>> >>>> 4. Deploy a Group Definition, which would logically group the relevant >>>> components. This would include information on the Startup Order of each >>>> component, and how to handle the termination/error situations as well (Kill >>>> Behavior). >>>> >>>> 5. Deploy a Nested Group Definition, which would contain one/more of >>>> Components and Groups. >>>> >>>> 6. Deploy the Composite Application Definition. This would map to the >>>> operation 'Subscription' which we have currently, when spinning up a single >>>> cartridge instance. As per the discussion that took place in the above >>>> mentioned thread, this was decided to be called the 'Composite >>>> Application Definition' deployment, rather than a Subscription. >>>> >>>> For the initial version, we can restrict this Composite Application >>>> Definition only to contain information for each group/component, such as >>>> aliases, git repositories and relevant info as required, etc., and not >>>> allow further grouping at this level. >>>> >>>> A typical basic Composite Application Definition, in JSON format, >>>> would be as follows: >>>> >>>> { >>>> "name": "group2", >>>> "alias": "<group2_alias>", >>>> "components": [ >>>> { >>>> "name": "component2", >>>> "alias": "<component2_alias>", >>>> "repoUrRL": "<repo_url>" >>>> } >>>> ], >>>> "groups": [ >>>> { >>>> "name": "group1", >>>> "alias": "group1_alias", >>>> "components": [ >>>> { >>>> "name": "component1", >>>> "alias": "<component1_alias>", >>>> "xxx": "<xxx>" >>>> }, >>>> { >>>> "name": "component3", >>>> "alias": "<component3_alias>", >>>> "yyy": "<yyy>" >>>> } >>>> ] >>>> } >>>> ] >>>> } >>>> >>>> More information is available in the above mentioned mail thread and in >>>> [2]. Please share your feedback on this. >>>> >>>> >>>> [1]. [Discuss] Grouping of services (cartridges) >>>> [2]. >>>> https://docs.google.com/a/wso2.com/document/d/1qnArxF8obhbjMLUbPAENQMn94fPSd3AVqO41mxhnJXE/edit# >>>> >>> >>> >> >> >> -- >> Imesh Gunaratne >> >> Technical Lead, WSO2 >> Committer & PPMC Member, Apache Stratos >> >> -- >> Thanks and Regards, >> >> Isuru H. >> +94 716 358 048* <http://wso2.com/>* >> >> >> * <http://wso2.com/>* >> >> >> -- Imesh Gunaratne Technical Lead, WSO2 Committer & PPMC Member, Apache Stratos
