stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Eppel (meppel)" <mep...@cisco.com>
Subject RE: Service Grouping and Composite Application Deployment
Date Mon, 07 Jul 2014 07:12:38 GMT
Great Thanks

Martin
From: isuruh@wso2.com [mailto:isuruh@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 <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.

​
[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>

Mime
View raw message