Great Thanks
Martin
From: [email protected] [mailto:[email protected]] 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
<[email protected]<mailto:[email protected]>> 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>
