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#
>

Reply via email to