stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Isuru Haththotuwa <isu...@apache.org>
Subject Re: Service Grouping and Composite Application Deployment
Date Sat, 05 Jul 2014 03:29:14 GMT
Hi Imesh,


On Fri, Jul 4, 2014 at 7:46 PM, Imesh Gunaratne <imesh@apache.org> 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?
>
This document is the initial proposal. It is a good starting point IMHO,
and covers the basic requirements for Service Grouping. However, as we go
along we might find that we don't need everything in the proposal/ there
additional functionality required. IMHO we can move forward with the
implementation, keeping the design open for extension to cater any future
requirements, as you have mentioned as well.

>
> [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>
> 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>
>> 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
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048* <http://wso2.com/>*
>
>
> * <http://wso2.com/>*
>
>
>

Mime
View raw message