stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Isuru Haththotuwa <isu...@apache.org>
Subject Re: Summary of Composite Application Definition with Reference to Deployed Service Groups discussion
Date Sun, 20 Jul 2014 15:19:42 GMT
Hi,

On Sun, Jul 20, 2014 at 4:43 PM, Shaheed Haque <shahhaqu@cisco.com> wrote:

>
>
> It seems to me that there are two ways to view of composite application.
> Either:
>
>
>
> - It is a specialised group, with all the attributes of a group, PLUS a
> "start top level group now" trigger
>
>
>
> - Just a "start top level group now" trigger
>
>
>
> At some point, I think I liked the former, but now I think that Martin's
> latter approach is cleaner. Also, I believe the composite application in
> Martin's model is almost completely empty (apart from a name and a top
> level group name or so), and if, in future, our view of an application is
> develops beyond what we need now, such a clean sheet would be a good place
> to start.
>
Good points Shaheedur. What I'm suggesting is that, in practical terms,
there can be a requirement such that we need to specify several groups and
cartridges in a Composite Application Definition, and a startup order
between them will be required naturally. Of course we can put that again in
to a single Group, and then use it in the Composite App Definition.
However, that would not enhance the re-usability of Groups, since we are
defining a Group for a specific purpose, not in a generic way.

>
>
>
>
> On Tuesday 15 Jul 2014 14:02:19 Martin Eppel wrote:
>
> > Hi Isuru,
>
> >
>
> > The way how I see it is that we are sneaking in an implicit group by
> specifying “top level” dependencies in composite application, not sure this
> is necessary. One idea of grouping is to be able to specify startup order
> or dependencies. Groups are still reusable although not all applications
> will use all groups, some groups might be specifically used by certain
> applications only, others not. The advantage,  at least I think,  we see
> with separating dependencies from subscription related information is that
> IMHO it will be less confusing to understand and also it will make for a
> cleaner implementation. At the end, either approach will work. Either way
> should be fine with me,
>
> >
>
> > Regards
>
> >
>
> > Martin
>
> >
>
> > From: isuruh@wso2.com [mailto:isuruh@wso2.com] On Behalf Of Isuru
> Haththotuwa
>
> > Sent: Tuesday, July 15, 2014 5:31 AM
>
> > To: dev
>
> > Cc: Martin Eppel (meppel); Udara Liyanage; Shaheedur Haque (shahhaqu);
> Lakmal Warusawithana (lakmal@wso2.com)
>
> > Subject: Re: Summary of Composite Application Definition with Reference
> to Deployed Service Groups discussion
>
> >
>
> > Hi Martin,
>
> >
>
> >
>
> > On Tue, Jul 15, 2014 at 5:15 PM, Martin Eppel (meppel) <meppel@cisco.com>
> wrote:
>
> > I agree with splitting it  into sub groups and cartridges – it will make
> it easier to parse and validation. I am not convinced we have to specify
> dependencies in the composite application also, I think we should not have
> to specify / distinguish top level groups ? We could base the assumption
> that a group / cartridge which has no dependency is standalone and can be
> started immediately ?
>
> > Yes, if there are no Dependencies specified in the Application
> Definition, we can start the Groups in parallel, then refer the relevant
> Group Definitions for the Stratup Order. That is not a problem. But, I
> think its a valid requirement have a startup order in the Application
> Definition so that cartridges are groups can be started in a particular
> order.
>
> >
>
> > In your example below the startup sequence would be (?) :
>
> >
>
> > cartridge.tomcat -> group.mygroup2 -> cartridge.php -> group.group1 ->
> mygroup1.mysql
>
> >
>
> > but I think the same could be modeled if we specify in group2 the
> following dependency:
>
> >
>
> > "dependencies": {
>
> >         "startupOrder": [
>
> >             {
>
> >                 "start": "group.group1",
>
> >                 "after": "cartridge.php"
>
> >             },
>
> > {
>
> >                 "start": "cartridge.php”,
>
> >                 "after": " cartridge.tomcat "  // has no dependency, can
> be started immediatly
>
> >             }
>
> > This would be fine if the Group 2 had the cartridge tomcat as well. But,
> if not, IMHO this is not correct. If we follow this model, a user might not
> be able to use only Group 2 in the application, but need to use tomcat
> cartridge as well. The idea of pre-deploying Group definitions is to make
> them re-usable.
>
> >
>
> >
>
> > I just would like to keep dependency and subscription information
> separate and don’t have to specify any dependency in the composite
> application, WDYT ?
>
> > As I mentioned above, the specifying dependencies in a Composite App is
> not mandatory. The user can create a Application Definition without it.
> IMHO there can be some information in Groups which can be overridden in
> Subscription time. As an example, in future, we could allow to define
> deployment and autoscaling policies in the group definition itself, and
> allow users to override those if they prefer at subscription time, by
> specifying different policies.
>
> >
>
> > Thanks
>
> >
>
> > Martin
>
> >
>
> > From: isuruh@wso2.com [mailto:isuruh@wso2.com] On Behalf Of Isuru
> Haththotuwa
>
> > Sent: Tuesday, July 15, 2014 4:02 AM
>
> > To: Martin Eppel (meppel)
>
> > Cc: Udara Liyanage; Isuru Haththotuwa; dev; Shaheedur Haque (shahhaqu);
> Lakmal Warusawithana (lakmal@wso2.com)
>
> > Subject: Re: Summary of Composite Application Definition with Reference
> to Deployed Service Groups discussion
>
> >
>
> > Hi Martin,
>
> >
>
> > I agree that this is simpler. However, in a Group, IMHO its better to
> have a way to separate out that particular Group's cartridges and sub
> groups. That will be very much easier in parsing and validating the
> Composite App Definition. Else, we need to separately check whether this is
> a group/cartridge,  and we can avoid that by specifying that its is either
> a cartridge or a nested Group.
>
> >
>
> > Also, we would need a method to specify a startup order and a kill
> behavior for the top level groups and cartridges. Therefore, I added a
> Dependency section as well.
>
> >
>
> > Please note I have referred to Cartridge Level Subscriptions as
> subscribables.
>
> >
>
> > Please find two sample Groups [1, 2] and a sample Composite App
> Definition [3]. WDYT?
>
> >
>
> > [1].
>
> > {
>
> >     "name": "group2",
>
> >     "subGroups": [
>
> >         "group1"
>
> >     ],
>
> >     "cartridges": [
>
> >         "php"
>
> >     ],
>
> >     "dependencies": {
>
> >         "startupOrder": [
>
> >             {
>
> >                 "start": "group.group1",
>
> >                 "after": "cartridge.php"
>
> >             }
>
> >     ],
>
> >         "killBehaviour": "kill-dependents"
>
> >     }
>
> > }
>
> >
>
> > [2].
>
> > {
>
> >     "name": "group1",
>
> >     "cartridges": [
>
> >         "mysql"
>
> >     ],
>
> >     "dependencies": {
>
> >         "killBehaviour": "kill-none"
>
> >     }
>
> > }
>
> >
>
> >
>
> > [3].
>
> > {
>
> >   "applicationId": "test_app",
>
> >   "components": {
>
> >     "groups": [
>
> >       {
>
> >         "name": "group2",
>
> >         "alias": "mygroup2",
>
> >         "deploymentPolicy": "dep_policy_group2",
>
> >         "autoscalingPolicy": "autoscale_policy_group2",
>
> >         "subscribables": [
>
> >           {
>
> >             "type": "php",
>
> >             "alias": "mygroup2.php",
>
> >
>
> >           }
>
> >         ],
>
> >         "subGroup": [
>
> >           {
>
> >             "name": "group1",
>
> >             "alias": "mygroup1",
>
> >
>
> >           }
>
> >         ],
>
> >
>
> >       },
>
> >       {
>
> >         "name": "group1",
>
> >         "alias": "mygroup1",
>
> >         "deploymentPolicy": "dep_policy_group1",
>
> >         "autoscalingPolicy": "autoscale_policy_group1",
>
> >         "subscribables": [
>
> >           {
>
> >             "type": "mysql",
>
> >             "alias": "mygroup1.mysql",
>
> >
>
> >           },
>
> >
>
> >         ],
>
> >
>
> >       },
>
> >
>
> >     ],
>
> >     "subscribables": [
>
> >       {
>
> >         "type": "tomcat",
>
> >         "alias": "mytomcat"
>
> >       }
>
> >     ],
>
> >     "dependencies": {
>
> >       "startupOrder": [
>
> >         {
>
> >           "start": "group.mygroup2",
>
> >           "after": "cartridge.tomcat"
>
> >         }
>
> >       ],
>
> >       "killBehaviour": "kill-dependents"
>
> >     },
>
> >
>
> >   },
>
> >   "subscribableInformation": [
>
> >     {
>
> >       "alias": "mygroup2.mysql",
>
> >       "deploymentPolicy": "dep_policy_mysql",
>
> >       "autoscalingPolicy": "autoscale_policy_mysql"
>
> >     },
>
> >     {
>
> >       "alias": "mygroup2.php",
>
> >       "deploymentPolicy": "dep_policy_php",
>
> >       "autoscalingPolicy": "autoscale_policy_php",
>
> >       "repoURL": "www.mygit.com/php.git",
>
> >       "privateRepo": "true",
>
> >       "repoUsername": "admin",
>
> >       "repoPassword": "xxxx"
>
> >     },
>
> >     {
>
> >       "alias": "mytomcat",
>
> >       "deploymentPolicy": "dep_policy_tomcat",
>
> >       "autoscalingPolicy": "autoscale_policy_tomcat",
>
> >       "repoURL": "www.mygit.com/tomcat.git",
>
> >       "privateRepo": "false",
>
> >       "repoUsername": "admin",
>
> >       "repoPassword": "yyyy"
>
> >     }
>
> >   ]
>
> > }
>
> >
>
> >
>
> > On Tue, Jul 15, 2014 at 2:18 PM, Martin Eppel (meppel) <meppel@cisco.com>
> wrote:
>
> > Hi Udara,
>
> >
>
> > I think we can flatten out the json structure and “simplify” a little
> bit more:
>
> >
>
> > As before in serviceGroup definitions we define a template of logical
> members and dependencies [1a], [1b] and [1c], while in the composite
> application [2] we define specific subscription instances. The composite
> application has 2 sections, groups and cartridges, each specifies the
> subscription instances of respective groups and cartridges and links them
> together in the subscribales section (list of subscribed group members:
> nested group subscription instances and cartridge subscription instances)
> of the group subscription.
>
> >
>
> > For instance, in the example below, I define a template for group1,
> group2 and group3. Group2 and group3 each have a dependency on group1 but
> different subscription instances (e.g. varying group auto scaling
> policies). In the (flat) group section we describe the subscription info
> for 2 variations of the group1 template, (each using different deployment
> policies and auto scaling policies). The subscription instance of group2
> (alias “mygroup2”) refers to a subscription instance of group1 with alias
> mygroup1 while  the subscription instance of group3 refers to a
> subscription instance of group1 with an alias of mygroup1b. group1
> subscriptions mygroup1 and mygroup1b each define different auto scaling /
> deployment policy.
>
> >
>
> > During deployment  we take the subscription instances and populate the
> “generic” dependency model (based on the serviceGroups) with specific
> subscription instances
>
> >
>
> > What do you think ?
>
> >
>
> > Thanks
>
> >
>
> > Martin
>
> >
>
> >
>
> > [1a]
>
> > {
>
> >     "name": "group1",
>
> >     "cartridges": [
>
> >         "mysql", "mongoDB"
>
> >     ],
>
> >     "dependencies": {
>
> >         "killBehaviour": "kill-none"
>
> >     }
>
> > }
>
> >
>
> > [1b]
>
> > {
>
> >     "name": "group2",
>
> >     "subGroups": [
>
> >         "group1"
>
> >     ],
>
> >     "cartridges": [
>
> >         "php", "app1"
>
> >     ],
>
> >     "dependencies": {
>
> >         "startupOrder": [
>
> >             {
>
> >                 "start": "cartridge.php",
>
> >                 "after": "group.group1"
>
> >             },
>
> >                                              {
>
> >                 "start": "cartridge.app1",
>
> >                 "after": "cartridge.php"
>
> >             }
>
> >          ],
>
> >         "killBehaviour": "kill-dependents"
>
> >     }
>
> > }
>
> >
>
> > [1c]
>
> > {
>
> >     "name": "group3",
>
> >     "subGroups": [
>
> >         "group1"
>
> >     ],
>
> >     "cartridges": [
>
> >         "app2"
>
> >     ],
>
> >     "dependencies": {
>
> >         "startupOrder": [
>
> >                                              {
>
> >                 "start": "cartridge.app2",
>
> >                 "after": "group.group1"
>
> >             }
>
> >          ],
>
> >         "killBehaviour": "kill-dependents"
>
> >     }
>
> > }
>
> > [2]
>
> > {
>
> >   "applicationId": "test_app",
>
> >   "alias": "myapp1",
>
> >   "components": [
>
> >     {
>
> >       "group": "group1",
>
> >       "alias": "mygroup1",
>
> >       "subscribables": [
>
> >         "mygroup1.mysql", "mygroup1.mongoDB"
>
> >       ]
>
> >     },
>
> >     {
>
> >       "group": "group1",
>
> >       "alias": "mygroup1b",
>
> >       "subscribables": [
>
> >         "mygroup1.mysql", "mygroup1.mongoDB"
>
> >       ]
>
> >     },
>
> >     {
>
> >       "group": "group2",
>
> >       "alias": "mygroup2",
>
> >       "subscribables": [
>
> >         { "mygroup1", "mygroup2.php", "mygroup2.app1"
>
> >         }
>
> >       ]
>
> >     },
>
> >     {
>
> >       "group": "group3",
>
> >       "alias": "mygroup3",
>
> >       "subscribables": [
>
> >                "mygroup1b", "mygroup3.app1"
>
> >       ]
>
> >     }
>
> >
>
> >   ],
>
> >   "groups": [
>
> >                {
>
> >       "group": "group1",
>
> >       "alias": "mygroup1",
>
> >       "deploymentPolicy": "dep_policy_group1",
>
> >       "autoscalingPolicy": "autoscale_policy_group1"
>
> >                },
>
> >                {
>
> >       "group": "group1",
>
> >       "alias": "mygroup1b",
>
> >       "deploymentPolicy": "dep_policy_group1b",
>
> >       "autoscalingPolicy": "autoscale_policy_group1b"
>
> >                },
>
> >                {
>
> >       "group": "group2",
>
> >       "alias": "mygroup2",
>
> >       "deploymentPolicy": "dep_policy_group2",
>
> >       "autoscalingPolicy": "autoscale_policy_group2"
>
> >                },
>
> >                {
>
> >       "group": "group3",
>
> >       "alias": "mygroup3",
>
> >       "deploymentPolicy": "dep_policy_group3",
>
> >       "autoscalingPolicy": "autoscale_policy_group3"
>
> >                }
>
> >   ],
>
> >
>
> >       "cartridges": [
>
> >                {
>
> >      "type": "mysql",
>
> >      "alias": "mygroup1.mysql",
>
> >      "deploymentPolicy": "dep_policy_mysql",
>
> >      "autoscalingPolicy": "autoscale_policy_mysql"
>
> >               },
>
> >               {
>
> >        "type": "mongoDB",
>
> >       "alias": "mygroup1.mongoDB",
>
> >        "deploymentPolicy": "dep_policy_mongoDB",
>
> >       "autoscalingPolicy": "autoscale_policy_mongoDB",
>
> >      "repoURL": "www.mygit.com/mongoDB.git",
>
> >       "privateRepo": "true",
>
> >       "repoUsername": "admin",
>
> >        "repoPassword": "xxxx"
>
> >      },
>
> >     {
>
> >       "type": "tomcat",
>
> >       "alias": "mytomcat",
>
> >       "deploymentPolicy": "dep_policy_tomcat",
>
> >       "autoscalingPolicy": "autoscale_policy_tomcat",
>
> >       "repoURL": "www.mygit.com/tomcat.git",
>
> >       "privateRepo": "false",
>
> >       "repoUsername": "admin",
>
> >       "repoPassword": "yyyy"
>
> >     },
>
> >                {
>
> >                  "type": "php",
>
> >                  "alias": "mygroup2.php",
>
> >                  "deploymentPolicy": "dep_policy_php",
>
> >                  "autoscalingPolicy": "autoscale_policy_php"
>
> >                },
>
> >                {
>
> >                  "type": "app1",
>
> >                  "alias": "mygroup2.app1",
>
> >                  "deploymentPolicy": "dep_policy_app1",
>
> >                  "autoscalingPolicy": "autoscale_policy_app1",
>
> >                  "repoURL": "www.mygit.com/app1.git",
>
> >                  "privateRepo": "true",
>
> >                  "repoUsername": "admin",
>
> >                  "repoPassword": "xxxx"
>
> >                },
>
> >                {
>
> >                  "type": "app1",
>
> >                  "alias": "mygroup3.app1",
>
> >                  "deploymentPolicy": "dep_policy_app1",
>
> >                  "autoscalingPolicy": "autoscale_policy_app1",
>
> >                  "repoURL": "www.mygit.com/app1.git",
>
> >                  "privateRepo": "true",
>
> >                  "repoUsername": "admin",
>
> >                  "repoPassword": "xxxx"
>
> >                }
>
> >   ]
>
> > }
>
> >
>
> > From: Udara Liyanage [mailto:udara@wso2.com]
>
> > Sent: Monday, July 14, 2014 10:11 PM
>
> > To: Isuru Haththotuwa
>
> > Cc: Martin Eppel (meppel); dev; Shaheedur Haque (shahhaqu); Lakmal
> Warusawithana (lakmal@wso2.com)
>
> > Subject: Re: Summary of Composite Application Definition with Reference
> to Deployed Service Groups discussion
>
> >
>
> >
>
> > I am refering to the composite app json you have pasted in the email.
>
> > There in components you have refered to the group "group1". Then
> subscribables are given to each cartridge. However if group1 refers to some
> other group (say group2), then arises the question how to specify
> subscribable details for the cartridges of group2. If we are to define them
> nested, I think json definition will become complex.
>
> > My suggestion is to define those refering groups as sub groups with an
> alias. Then later we define the subscribable details with this alias.
>
> > Assume that group2 has mongoDb cartridge defined and group1 refers to
> group2. In components we specify the group2 as below
>
> >
>
> > "subGroup": [
>
> >           {
>
> >             "name": "group2",
>
> >             "alias": "mygroup2",
>
> >
>
> >           }
>
> >         ],
>
> >
>
> > We add alias "mygroup2" to refer to the group2. Then at
> subscribableInformation section we provide sunscription details for the
> group2 mongoDb cartridge.
>
> >
>
> >   "subscribableInformation": [
>
> >     {
>
> >       "alias": "mygroup2.mongo",
>
> >       "deploymentPolicy": "dep_policy_mongo",
>
> >       "autoscalingPolicy": "autoscale_mongo"
>
> >     },
>
> >
>
> > I have pasted the whole json below. Let me know your feedback
>
> >
>
> > {
>
> >   "applicationId": "test_app",
>
> >   "alias": "myapp1",
>
> >   "components": {
>
> >     "groups": [
>
> >       {
>
> >         "name": "group1",
>
> >         "alias": "mygroup1",
>
> >         "deploymentPolicy": "dep_policy_group1",
>
> >         "autoscalingPolicy": "autoscale_policy_group1",
>
> >         "subscribables": [
>
> >           {
>
> >             "type": "mysql",
>
> >             "alias": "mygroup1.mysql",
>
> >
>
> >           },
>
> >           {
>
> >             "type": "php",
>
> >             "alias": "mygroup1.php"
>
> >           },
>
> >
>
> >         ],
>
> >         "subGroup": [
>
> >           {
>
> >             "name": "group2",
>
> >             "alias": "mygroup2",
>
> >
>
> >           }
>
> >         ],
>
> >
>
> >       },
>
> >       {
>
> >         "name": "group2",
>
> >         "alias": "mygroup2",
>
> >         "deploymentPolicy": "dep_policy_group2",
>
> >         "autoscalingPolicy": "autoscale_policy_group2",
>
> >         "subscribables": [
>
> >           {
>
> >             "type": "mongo",
>
> >             "alias": "mygroup2.mongo",
>
> >
>
> >           },
>
> >
>
> >         ],
>
> >
>
> >       },
>
> >
>
> >     ],
>
> >     "subscribables": [
>
> >       {
>
> >         "type": "tomcat",
>
> >         "alias": "mytomcat"
>
> >       }
>
> >     ],
>
> >     "dependencies": {
>
> >       "startupOrder": [
>
> >         {
>
> >           "start": "group.mygroup1",
>
> >           "after": "cartridge.tomcat"
>
> >         }
>
> >       ],
>
> >       "killBehaviour": "kill-dependents"
>
> >     },
>
> >
>
> >   },
>
> >   "subscribableInformation": [
>
> >     {
>
> >       "alias": "mygroup1.mysql",
>
> >       "deploymentPolicy": "dep_policy_mysql",
>
> >       "autoscalingPolicy": "autoscale_policy_mysql"
>
> >     },
>
> >     {
>
> >       "alias": "mygroup2.mongo",
>
> >       "deploymentPolicy": "dep_policy_mongo",
>
> >       "autoscalingPolicy": "autoscale_mongo"
>
> >     },
>
> >     {
>
> >       "alias": "mygroup1.php",
>
> >       "deploymentPolicy": "dep_policy_php",
>
> >       "autoscalingPolicy": "autoscale_policy_php",
>
> >       "repoURL": "www.mygit.com/php.git",
>
> >       "privateRepo": "true",
>
> >       "repoUsername": "admin",
>
> >       "repoPassword": "xxxx"
>
> >     },
>
> >     {
>
> >       "alias": "mytomcat",
>
> >       "deploymentPolicy": "dep_policy_tomcat",
>
> >       "autoscalingPolicy": "autoscale_policy_tomcat",
>
> >       "repoURL": "www.mygit.com/tomcat.git",
>
> >       "privateRepo": "false",
>
> >       "repoUsername": "admin",
>
> >       "repoPassword": "yyyy"
>
> >     }
>
> >   ]
>
> > }
>
> >
>
> >
>
> > On Sun, Jul 13, 2014 at 7:44 PM, Isuru Haththotuwa <isuruh@apache.org>
> wrote:
>
> >
>
> >
>
> >
>
> > On Fri, Jul 11, 2014 at 5:25 PM, Martin Eppel (meppel) <meppel@cisco.com>
> wrote:
>
> > Hi Udara,
>
> >
>
> > The changes look good, one  comment:
>
> >
>
> > ComponentDefinition.java :
>
> > I think dependencies need to be removed from ComponentDefinition
>  (“public ConfigDependencies dependencies;”), should be describes as part
> of the ServiceGroup, what do you think ?
>
> > +1.
>
> >
>
> > Thanks
>
> >
>
> > Martin
>
> >
>
> >
>
> >
>
> > From: Udara Liyanage [mailto:udara@wso2.com]
>
> > Sent: Friday, July 11, 2014 1:57 AM
>
> > To: Martin Eppel (meppel)
>
> > Cc: dev; Shaheedur Haque (shahhaqu); Isuru Haththotuwa (isuruh@wso2.com);
> Lakmal Warusawithana (lakmal@wso2.com)
>
> >
>
> > Subject: Re: Summary of Composite Application Definition with Reference
> to Deployed Service Groups discussion
>
> >
>
> > Hi Martin,
>
> >
>
> > Change is based on remotes/origin/4.0.0-grouping branch.
>
> >
>
> >
>
> > On Fri, Jul 11, 2014 at 2:16 PM, Martin Eppel (meppel) <meppel@cisco.com>
> wrote:
>
> > Hi Udara,
>
> >
>
> > Which branch are your changes based on ?
>
> >
>
> > From: Udara Liyanage [mailto:udara@wso2.com]
>
> > Sent: Thursday, July 10, 2014 11:39 PM
>
> > To: dev
>
> > Cc: Martin Eppel (meppel); Shaheedur Haque (shahhaqu); Isuru Haththotuwa
> (isuruh@wso2.com); Lakmal Warusawithana (lakmal@wso2.com)
>
> >
>
> > Subject: Re: Summary of Composite Application Definition with Reference
> to Deployed Service Groups discussion
>
> >
>
> > Hi Reka and Martin,
>
> >
>
> > I made changes according to the last json format sent by Martin. I have
> attached the diff before commiting. Could someone have a glance.
>
> > Please note that I did not consider the scenario of nested group
> scenario for simplicity.
>
> >
>
> >
>
> > On Wed, Jul 9, 2014 at 1:39 PM, Reka Thirunavukkarasu <reka@wso2.com>
> wrote:
>
> > Thanks Martin..
>
> >
>
> >
>
> > On Wed, Jul 9, 2014 at 1:34 PM, Martin Eppel (meppel) <meppel@cisco.com>
> wrote:
>
> > Hi Reka,
>
> >
>
> > Actually I just copied the example from one of the previous emails
> (Imesh and Isuru’s emails) as examples.
>
> >
>
> > But I think you are right, the composite application defines these
> parameters (in the subscribable section) for each cartridge or sub group as
> defined in the service group. From example [1] in group1 it  lists
> cartridges mongodb and mysql which should also be listed in the
> subscribable section of the composite application (instead of php).
>
> > +1. Now it is clear...
>
> >
>
> > Thanks
>
> >
>
> > Martin
>
> >
>
> > From: Reka Thirunavukkarasu [mailto:reka@wso2.com]
>
> > Sent: Wednesday, July 09, 2014 12:37 AM
>
> > To: Martin Eppel (meppel)
>
> > Cc: dev@stratos.apache.org; Shaheedur Haque (shahhaqu); Isuru
> Haththotuwa (isuruh@wso2.com); Lakmal Warusawithana (lakmal@wso2.com)
>
> > Subject: Re: Summary of Composite Application Definition with Reference
> to Deployed Service Groups discussion
>
> >
>
> > Hi Martin,
>
> >
>
> > Thanks for the summary...I have a small doubt with Composite Application
> Model. It is mentioned as below..
>
> >
>
> >
>
> > On Tue, Jul 8, 2014 at 8:07 PM, Martin Eppel (meppel) <meppel@cisco.com>
> wrote:
>
> > I browsed over the previously exchanged emails, compiled and summarized
> it below (please correct me when my understanding is incorrect).
>
> >
>
> > + service Groups definitions are deployed independently of each other
> (similar to deploying a cartridge or policy)
>
> >    (something along the lines like “deploy-service-group service-group-
> definition.json”, for sample definition see [1], [2])
>
> > + service Groups are named and can be referenced in a composite
> application
>
> > + generally, service groups logically groups other service group
> definitions and cartridge types and describes their interdependencies
>
> > + dependencies are described as part of the service group definition
>
> > + For the format and examples of a service group see [1], [2] below
>
> > + other characteristics of service groups like auto-scaling, deployment
> restrictions  are describes as part of the composite application
>
> >
>
> >
>
> > + Composite application is deployed independent of service groups
>
> > + composite application references (already deployed) service groups and
> cartridges
>
> > + provides required subscription and deployment  information for service
> group definitions and cartridge types
>
> > + creates a specific instance of a service group / cartridge type by
> defining a service group alias and cartridge alias and also by assigning
> characteristics like auto-scaling, deployment policy, etc … which are
> specific for the application (for instance another application could define
> other deployment policies for the same service group definition)
>
> > + composite application format and example see [3]
>
> > In [3] as you have referenced "group1", then don't we need to specify
> the characteristics against the group/cartridge type which used in "group1"
> ? In that case, we need to specify only for mongoDB as well as group1 based
> characteristics? Please correct me, if i'm wrong..
>
> >
>
> > Thanks,
>
> > Reka
>
> >
>
> > + N number of applications will be supported ?
>
> >
>
> >
>
> >
>
> > {
>
> >     "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"
>
> >
>
> >     }
>
> > }
>
> >
>
> > [3]
>
> >
>
> > {
>
> >   "applicationId": "test_app",
>
> >   "alias": "myapp1",
>
> >   "components": [
>
> >     {
>
> >       "group": "group1",
>
> >       "alias": "mygroup1",
>
> >       "deploymentPolicy": "dep_policy_group1",
>
> >       "autoscalingPolicy": "autoscale_policy_group1",
>
> >       "subscribables": [
>
> >         {
>
> >           "type": "mysql",
>
> >           "alias": "mygroup1.mysql",
>
> >           "deploymentPolicy": "dep_policy_mysql",
>
> >           "autoscalingPolicy": "autoscale_policy_mysql"
>
> >         },
>
> >         {
>
> >           "type": "php",
>
> >           "alias": "mygroup1.php",
>
> >           "deploymentPolicy": "dep_policy_php",
>
> >           "autoscalingPolicy": "autoscale_policy_php",
>
> >           "repoURL": "www.mygit.com/php.git",
>
> >           "privateRepo": "true",
>
> >           "repoUsername": "admin",
>
> >           "repoPassword": "xxxx"
>
> >         }
>
> >       ]
>
> >     },
>
> >
>
> >   ],
>
> >   "cartridges": [
>
> >     {
>
> >       "type": "tomcat",
>
> >       "alias": "mytomcat",
>
> >       "deploymentPolicy": "dep_policy_tomcat",
>
> >       "autoscalingPolicy": "autoscale_policy_tomcat",
>
> >       "repoURL": "www.mygit.com/tomcat.git",
>
> >       "privateRepo": "false",
>
> >       "repoUsername": "admin",
>
> >       "repoPassword": "yyyy"
>
> >     }
>
> >   ]
>
> > }
>
> >
>
> > From: Shaheedur Haque (shahhaqu)
>
> > Sent: Tuesday, July 08, 2014 3:16 AM
>
> > To: dev@stratos.apache.org; Martin Eppel (meppel)
>
> > Subject: RE: Composite Application Definition with Reference to Deployed
> Service Groups
>
> >
>
> > Hi Isuru,
>
> >
>
> > See below…
>
> >
>
> > From: isuruh@wso2.com [mailto:isuruh@wso2.com] On Behalf Of Isuru
> Haththotuwa
>
> > Sent: 04 July 2014 09:11
>
> > To: dev; Martin Eppel (meppel)
>
> > Subject: Composite Application Definition with Reference to Deployed
> Service Groups
>
> >
>
> > Hi all,
>
> >
>
> > Since we have the Service Group persistence now, we can change the
> Composite Application to refer the previously deployed Service Groups [1].
> WDYT?
>
> >
>
> > [srh] I think I missed groups being deployed/persisted separately. Does
> the “subscription” information (meaning deployment and autoscaling only for
> a group, everything for a cartridge), get persisted with each group?
>
> >
>
> >
>
> > The Subscribable section will carry subscription level information
> related to each cartridge in the group. Even for a nested group, we can
> specify this information as a flat structure (an array) since we already
> have captured dependency information from the deployed Service Groups. I
> believe this will reduce the complexity of this JSON definition. Note that
> there are policies (autoscaling/deployment) defined per group and per
> Subscribable. This is for the purpose of member/group wise scaling. Also
> note the alias I have used for two Subscribables in the group; I believe we
> can derive that from the group alias without the user having to give an
> explicit alias for each Subscribable. Sent a separate mail to the dev list
> suggesting that earlier with subject [2].
>
> >
>
> > [srh] Some questions:
>
> >
>
> > 1.      I think I don’t understand what application.components is, I
> imagined it rather as application.groups? That way, the application is
> itself just a subclass of group, albeit the one at the top and carrying any
> specialisation that implies.
>
> >
>
> > 2.      In [1] you don’t show nested groups. How should those be
> represented? Or are they not needed because groups are being
> deployed/persisted separately, and this application only specifies the top
> level groups/cartridges and their respective “subscriptions”?
>
> >
>
> >
>
> > I’m a little uneasy about the inline model of the “subscription”
> information. I tend to think that this can be factored out (though it is
> not the end of the world to keep it inline) subject to my understanding of
> questions 1 and 2.
>
> >
>
> > BTW, I saw this email after I responded to [2] J
>
> >
>
> > Thanks, Shaheed
>
> >
>
> > [1].
>
> > {
>
> >   "applicationId": "test_app",
>
> >   "alias": "myapp1",
>
> >   "components": [
>
> >     {
>
> >       "group": "group1",
>
> >       "alias": "mygroup1",
>
> >       "deploymentPolicy": "dep_policy_group1",
>
> >       "autoscalingPolicy": "autoscale_policy_group1",
>
> >       "subscribables": [
>
> >         {
>
> >           "type": "mysql",
>
> >           "alias": "mygroup1.mysql",
>
> >           "deploymentPolicy": "dep_policy_mysql",
>
> >           "autoscalingPolicy": "autoscale_policy_mysql"
>
> >         },
>
> >         {
>
> >           "type": "php",
>
> >           "alias": "mygroup1.php",
>
> >           "deploymentPolicy": "dep_policy_php",
>
> >           "autoscalingPolicy": "autoscale_policy_php",
>
> >           "repoURL": "www.mygit.com/php.git",
>
> >           "privateRepo": "true",
>
> >           "repoUsername": "admin",
>
> >           "repoPassword": "xxxx"
>
> >         }
>
> >       ]
>
> >     },
>
> >
>
> >   ],
>
> >   "cartridges": [
>
> >     {
>
> >       "type": "tomcat",
>
> >       "alias": "mytomcat",
>
> >       "deploymentPolicy": "dep_policy_tomcat",
>
> >       "autoscalingPolicy": "autoscale_policy_tomcat",
>
> >       "repoURL": "www.mygit.com/tomcat.git",
>
> >       "privateRepo": "false",
>
> >       "repoUsername": "admin",
>
> >       "repoPassword": "yyyy"
>
> >     }
>
> >   ]
>
> > }
>
> >
>
> >
>
> > [2]. Composite Application Deployment and Subscription - Single Alias
> for a Group
>
> >
>
> > --
>
> > Thanks and Regards,
>
> >
>
> > Isuru H.
>
> > +94 716 358 048
>
> >
>
> >
>
> >
>
> >
>
> > --
>
> > Reka Thirunavukkarasu
>
> > Senior Software Engineer,
>
> > WSO2, Inc.:http://wso2.com,
>
> > Mobile: +94776442007
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > --
>
> > Reka Thirunavukkarasu
>
> > Senior Software Engineer,
>
> > WSO2, Inc.:http://wso2.com,
>
> > Mobile: +94776442007
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > --
>
> >
>
> > Udara Liyanage
>
> > Software Engineer
>
> > WSO2, Inc.: http://wso2.com
>
> > lean. enterprise. middleware
>
> >
>
> > web: http://udaraliyanage.wordpress.com
>
> > phone: +94 71 443 6897
>
> >
>
> >
>
> >
>
> > --
>
> >
>
> > Udara Liyanage
>
> > Software Engineer
>
> > WSO2, Inc.: http://wso2.com
>
> > lean. enterprise. middleware
>
> >
>
> > web: http://udaraliyanage.wordpress.com
>
> > phone: +94 71 443 6897
>
> >
>
> > --
>
> > Thanks and Regards,
>
> >
>
> > Isuru H.
>
> > +94 716 358 048
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > --
>
> >
>
> > Udara Liyanage
>
> > Software Engineer
>
> > WSO2, Inc.: http://wso2.com
>
> > lean. enterprise. middleware
>
> >
>
> > web: http://udaraliyanage.wordpress.com
>
> > phone: +94 71 443 6897
>
> >
>
> > --
>
> >
>
> > Thanks and Regards,
>
> >
>
> > Isuru H.
>
> >
>
> > +94 716 358 048
>
> >
>
> > --
>
> >
>
> > Thanks and Regards,
>
> >
>
> > Isuru H.
>
> > +94 716 358 048
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048* <http://wso2.com/>*
>
>
> * <http://wso2.com/>*
>
>
>

Mime
View raw message