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 Tue, 15 Jul 2014 11:02:17 GMT
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 <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
>
> --
>  <%2B94%2071%20443%206897>
>
> Thanks and Regards,
>
> Isuru H.
>  <%2B94%2071%20443%206897>
>
> +94 716 358 048 <%2B94%2071%20443%206897>
>
>
>
>
>
>
>
> --
>
>
> 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* <http://wso2.com/>*
>
>
> * <http://wso2.com/>*
>
>
>

Mime
View raw message