brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nirmal Fernando <nirmal070...@gmail.com>
Subject Re: Service Grouping and Composite Application Deployment
Date Tue, 08 Jul 2014 02:56:08 GMT
Thanks for bringing this up Alex. There're few people in the list who had a
look at the CAMP spec.

I totally agree, that we should leverage existing implementations such as
Brooklyn.

On Mon, Jul 7, 2014 at 2:47 AM, Alex Heneveld <
alex.heneveld@cloudsoftcorp.com> wrote:

>
> Hi folks,
>
> // cross-post stratos and brooklyn mailing lists
>
> Two suggestions.
>
> First one is that Stratos should look at adopting at least one of these
> official specs -- CAMP or TOSCA -- now rather than later.  Both have
> matured a lot in recent months and would suit the purpose nicely from what
> I see.  "Cartridges" seem to map fairly neatly into CAMP components / TOSCA
> nodes, and "dependencies" to requirements/characteristics/relationships.
>
> Disclaimer:  I am on the TC for these specs, but mainly because I don't
> like different, proprietary formats unless there is a real need for it,
> hence making this suggestion!  It would also have the nice benefit of
> aligning Apache Stratos with OpenStack projects Heat and Solum as well as
> neighbouring Apache (incubating) project Brooklyn [1].)
>
>
> Second suggestion is that Stratos could leverage some of the work we've
> been doing in Apache-incubating Brooklyn.
>
> Last week CAMP support was officially contributed -- both YAML description
> and REST API (although a slightly out-of-date version, to be updated
> soon!).  We're expecting to have TOSCA simple profile YAML support
> developed this year.
>
> Brooklyn is Java-based, lower level than Stratos, designed to support
> exactly the type of service composition designed here, so I think it could
> be a good fit saving a lot of headaches and wheel-reinvention.  There is
> some overlap but essentially Brooklyn does NOT try to be the services, it
> is great and composition, management, and clouds, but agnostic about the
> things Stratos cares most about, at least from what I understand.
>
> Another disclaimer:  I am on PPMC for Brooklyn.  That said, if we in the
> Brooklyn community can help, please let us know.  Some of you may know us
> from lots of jclouds contributions or early Stratos discussions.  We're
> also on IRC at #brooklyncentral.
>
> Best
> Alex
>
> [1]  http://brooklyn.incubator.apache.org/
>
>
>
> On 04/07/2014 15:16, Imesh Gunaratne 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?
>
>  [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
>
>
>


-- 
Best Regards,
Nirmal

Nirmal Fernando.
PPMC Member & Committer of Apache Stratos,
Senior Software Engineer, WSO2 Inc.

Blog: http://nirmalfdo.blogspot.com/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message