You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Alex Heneveld <al...@cloudsoftcorp.com> on 2014/07/07 11:47:53 UTC
Re: Service Grouping and Composite Application Deployment
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
> <ma...@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 <ma...@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
Re: Service Grouping and Composite Application Deployment
Posted by Lakmal Warusawithana <la...@wso2.com>.
Hi Alex,
Thanks for bringing up this. IFAIK, couple of devs looked at CAMP, and its
really comprehensive spec. But IMHO, fully adopting to CAMP may be bit
harder. Stratos has already implemented some of them and writing for CAMP
is not such easy. But we have looked at CAMP when we started this grouping
and followed as much as AFAIK.
I also like to have a look more on Brooklyn (I looked at glance). May be
we can integrate to Stratos.
On Tue, Jul 8, 2014 at 8:26 AM, Nirmal Fernando <ni...@gmail.com>
wrote:
> 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 <is...@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 <is...@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/
>
--
Lakmal Warusawithana
Vice President, Apache Stratos
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: Service Grouping and Composite Application Deployment
Posted by Lakmal Warusawithana <la...@wso2.com>.
Hi Alex,
Thanks for bringing up this. IFAIK, couple of devs looked at CAMP, and its
really comprehensive spec. But IMHO, fully adopting to CAMP may be bit
harder. Stratos has already implemented some of them and writing for CAMP
is not such easy. But we have looked at CAMP when we started this grouping
and followed as much as AFAIK.
I also like to have a look more on Brooklyn (I looked at glance). May be
we can integrate to Stratos.
On Tue, Jul 8, 2014 at 8:26 AM, Nirmal Fernando <ni...@gmail.com>
wrote:
> 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 <is...@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 <is...@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/
>
--
Lakmal Warusawithana
Vice President, Apache Stratos
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: Service Grouping and Composite Application Deployment
Posted by Nirmal Fernando <ni...@gmail.com>.
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 <is...@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 <is...@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/
Re: Service Grouping and Composite Application Deployment
Posted by Nirmal Fernando <ni...@gmail.com>.
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 <is...@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 <is...@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/