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