Great Thanks Martin From: isu...@wso2.com [mailto:isu...@wso2.com] On Behalf Of Isuru Haththotuwa Sent: Thursday, July 03, 2014 9:22 AM To: dev Cc: Martin Eppel (meppel); Lakmal Warusawithana Subject: Re: Service Grouping and Composite Application Deployment
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<mailto: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. [https://ssl.gstatic.com/docs/doclist/images/icon_10_generic_list.png] 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#<https://docs.google.com/a/wso2.com/document/d/1qnArxF8obhbjMLUbPAENQMn94fPSd3AVqO41mxhnJXE/edit>