brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Subject Re: Service Grouping and Composite Application Deployment
Date Mon, 07 Jul 2014 09:47:53 GMT

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 <isuruh@apache.org 
> <mailto:isuruh@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
>     <isuruh@apache.org <mailto:isuruh@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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message