Thanks for bringing this up Alex. There're few people in the list who had a look at the CAMP spec.
I totally agree, that we should leverage existing implementations such as Brooklyn. On Mon, Jul 7, 2014 at 2:47 AM, Alex Heneveld < alex.henev...@cloudsoftcorp.com> wrote: > > Hi folks, > > // cross-post stratos and brooklyn mailing lists > > Two suggestions. > > First one is that Stratos should look at adopting at least one of these > official specs -- CAMP or TOSCA -- now rather than later. Both have > matured a lot in recent months and would suit the purpose nicely from what > I see. "Cartridges" seem to map fairly neatly into CAMP components / TOSCA > nodes, and "dependencies" to requirements/characteristics/relationships. > > Disclaimer: I am on the TC for these specs, but mainly because I don't > like different, proprietary formats unless there is a real need for it, > hence making this suggestion! It would also have the nice benefit of > aligning Apache Stratos with OpenStack projects Heat and Solum as well as > neighbouring Apache (incubating) project Brooklyn [1].) > > > Second suggestion is that Stratos could leverage some of the work we've > been doing in Apache-incubating Brooklyn. > > Last week CAMP support was officially contributed -- both YAML description > and REST API (although a slightly out-of-date version, to be updated > soon!). We're expecting to have TOSCA simple profile YAML support > developed this year. > > Brooklyn is Java-based, lower level than Stratos, designed to support > exactly the type of service composition designed here, so I think it could > be a good fit saving a lot of headaches and wheel-reinvention. There is > some overlap but essentially Brooklyn does NOT try to be the services, it > is great and composition, management, and clouds, but agnostic about the > things Stratos cares most about, at least from what I understand. > > Another disclaimer: I am on PPMC for Brooklyn. That said, if we in the > Brooklyn community can help, please let us know. Some of you may know us > from lots of jclouds contributions or early Stratos discussions. We're > also on IRC at #brooklyncentral. > > Best > Alex > > [1] http://brooklyn.incubator.apache.org/ > > > > On 04/07/2014 15:16, Imesh Gunaratne 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? > > [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 > > > -- Best Regards, Nirmal Nirmal Fernando. PPMC Member & Committer of Apache Stratos, Senior Software Engineer, WSO2 Inc. Blog: http://nirmalfdo.blogspot.com/
