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/>* > > >
