Return-Path: X-Original-To: apmail-stratos-dev-archive@minotaur.apache.org Delivered-To: apmail-stratos-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2D8EC11743 for ; Sun, 20 Jul 2014 15:20:18 +0000 (UTC) Received: (qmail 51408 invoked by uid 500); 20 Jul 2014 15:20:17 -0000 Delivered-To: apmail-stratos-dev-archive@stratos.apache.org Received: (qmail 51355 invoked by uid 500); 20 Jul 2014 15:20:17 -0000 Mailing-List: contact dev-help@stratos.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stratos.apache.org Delivered-To: mailing list dev@stratos.apache.org Received: (qmail 51345 invoked by uid 99); 20 Jul 2014 15:20:17 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 20 Jul 2014 15:20:17 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of isuruh@wso2.com designates 209.85.217.173 as permitted sender) Received: from [209.85.217.173] (HELO mail-lb0-f173.google.com) (209.85.217.173) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 20 Jul 2014 15:20:09 +0000 Received: by mail-lb0-f173.google.com with SMTP id p9so917699lbv.4 for ; Sun, 20 Jul 2014 08:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wso2.com; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=f3EPdfA4qDuyRzCpfTii9Xl2ENGS0I+OwGIXvS7TKAs=; b=ON6Jxb1OOx5nIZETLKMysLnPhkgUOnpwnMYl1aABThxmR9uhzfatYj7XBX8v+Cc6CY rVKfBy5ub+8krJcrNvWpgxk9gA/n4/E9Z3MN04//QCHX1+0xT54B/HRIzXyjWehIqGgG 2P0mJOZHvpCcDBj8hzng19Uvcb3Hah72oQAhI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=f3EPdfA4qDuyRzCpfTii9Xl2ENGS0I+OwGIXvS7TKAs=; b=MfPqq+xYQOzVCcS3zMrPEmBntCNAFJHrBo96SQ4jOY0VZ3t13ZwpWg6fUjqw5ULzEh 5CWGUVlIIvmIJ9/Qzy+9i8kDmol6159zsN1hYCurOkfkXIQeQVdLhykVO8HTRPeFXUP2 +IWDe3vUKV1Q+Y4H71LCeAMmIvpw0QN7GB6zhF6LxU3PHwS37sAIz7sxJJDZC/xHkapo yztzooSMBJvi5FeZIyUYCb6ofBpziyfar9trhjTdFhGmUUK/0yETNxTQ5qTfOmuc5F4Z nK66aVNWxmk94kpZIUbq2ZuwRDwS8B4EV35hgaeW6pxSpXMwD2Ms4+1FKV6GDNQkSL1E imVw== X-Gm-Message-State: ALoCoQnZ7J+G56RCT2xnGMA3CQyy2i42rYNUcYzyPEnySeY9HvEtcZz01r8Aez7MUqXLyz+xQFGp MIME-Version: 1.0 X-Received: by 10.112.16.230 with SMTP id j6mr3604341lbd.90.1405869582462; Sun, 20 Jul 2014 08:19:42 -0700 (PDT) Sender: isuruh@wso2.com Received: by 10.112.198.169 with HTTP; Sun, 20 Jul 2014 08:19:42 -0700 (PDT) In-Reply-To: <4301595.iO9ADI1oSm@shahhaqu-w530> References: <07110D8A7AC60C49AE2432100017A3F627761A31@xmb-rcd-x12.cisco.com> <07110D8A7AC60C49AE2432100017A3F6277630B6@xmb-rcd-x12.cisco.com> <4301595.iO9ADI1oSm@shahhaqu-w530> Date: Sun, 20 Jul 2014 20:49:42 +0530 X-Google-Sender-Auth: bATJSWHpwlcwA5OjK4T8wXuuTLU Message-ID: Subject: Re: Summary of Composite Application Definition with Reference to Deployed Service Groups discussion From: Isuru Haththotuwa To: Shaheed Haque Cc: "Martin Eppel (meppel)" , Isuru Haththotuwa , dev , Udara Liyanage , "Lakmal Warusawithana (lakmal@wso2.com)" Content-Type: multipart/alternative; boundary=001a11c3c6d21051f004fea1856d X-Virus-Checked: Checked by ClamAV on apache.org --001a11c3c6d21051f004fea1856d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Sun, Jul 20, 2014 at 4:43 PM, Shaheed Haque 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 plac= e > 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 =E2=80=9Ctop level=E2=80=9D dependencies in composite applicat= ion, 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 tha= t > 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) > wrote: > > > I agree with splitting it into sub groups and cartridges =E2=80=93 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 hav= e > 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=E2=80=9D, > > > "after": " cartridge.tomcat " // has no dependency, ca= n > 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 n= ot > 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=E2=80=99t have to specify any dependency in the composit= e > 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 eithe= r > 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) > wrote: > > > Hi Udara, > > > > > > I think we can flatten out the json structure and =E2=80=9Csimplify=E2= =80=9D 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 =E2=80=9Cmygroup2=E2=80=9D) refers to a subscription instance of g= roup1 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 > =E2=80=9Cgeneric=E2=80=9D dependency model (based on the serviceGroups) w= ith 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 so= me > other group (say group2), then arises the question how to specify > subscribable details for the cartridges of group2. If we are to define th= em > 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 > wrote: > > > > > > > > > > > > On Fri, Jul 11, 2014 at 5:25 PM, Martin Eppel (meppel) > wrote: > > > Hi Udara, > > > > > > The changes look good, one comment: > > > > > > ComponentDefinition.java : > > > I think dependencies need to be removed from ComponentDefinition > (=E2=80=9Cpublic ConfigDependencies dependencies;=E2=80=9D), should be d= escribes 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) > 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 Haththotuw= a > (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 > wrote: > > > Thanks Martin.. > > > > > > > > > On Wed, Jul 9, 2014 at 1:34 PM, Martin Eppel (meppel) > wrote: > > > Hi Reka, > > > > > > Actually I just copied the example from one of the previous emails > (Imesh and Isuru=E2=80=99s 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 Applicatio= n > Model. It is mentioned as below.. > > > > > > > > > On Tue, Jul 8, 2014 at 8:07 PM, Martin Eppel (meppel) > 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 =E2=80=9Cdeploy-service-group servic= e-group- > definition.json=E2=80=9D, 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 an= d > cartridges > > > + provides required subscription and deployment information for servic= e > 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 =E2=80=A6 which= are > specific for the application (for instance another application could defi= ne > 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 "group= 1" > ? In that case, we need to specify only for mongoDB as well as group1 bas= ed > 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 Deploye= d > Service Groups > > > > > > Hi Isuru, > > > > > > See below=E2=80=A6 > > > > > > 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 =E2=80=9Csubscription=E2=80=9D information (meaning deployment and au= toscaling 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 tha= t > 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 lis= t > suggesting that earlier with subject [2]. > > > > > > [srh] Some questions: > > > > > > 1. I think I don=E2=80=99t 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 a= ny > specialisation that implies. > > > > > > 2. In [1] you don=E2=80=99t show nested groups. How should those b= e > represented? Or are they not needed because groups are being > deployed/persisted separately, and this application only specifies the to= p > level groups/cartridges and their respective =E2=80=9Csubscriptions=E2=80= =9D? > > > > > > > > > I=E2=80=99m a little uneasy about the inline model of the =E2=80=9Csubs= cription=E2=80=9D > 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 o= f > 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* * > > > * * > > > --001a11c3c6d21051f004fea1856d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

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

=C2=A0

It seems to me that there are two ways to view of compo= site application. Either:

=C2=A0

- It is a specialised group, with all the attributes o= f a group, PLUS a "start top level group now" trigger

=C2=A0

- Just a "start top level group now" trigger=

=C2=A0

At some point, I think I liked the former, but now I th= ink that Martin's latter approach is cleaner. Also, I believe the compo= site application in Martin's model is almost completely empty (apart fr= om 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 wou= ld be a good place to start.

Good points Shaheedur. What I'm suggesting is t= hat, in practical terms, there can be a requirement such that we need to sp= ecify several groups and cartridges in a Composite Application Definition, = and a startup order between them will be required naturally. Of course we c= an put that again in to a single Group, and then use it in the Composite Ap= p Definition. However, that would not enhance the re-usability of Groups, s= ince we are defining a Group for a specific purpose, not in a generic way. =

=C2=A0

=C2=A0

On Tuesday 15 Jul 2014 14:02:19 Martin Eppel wrote:

> Hi Isuru,

> =C2=A0

> The way how I see it is that we are sneaking in an= implicit group by specifying =E2=80=9Ctop level=E2=80=9D dependencies in c= omposite application, not sure this is necessary. One idea of grouping is t= o be able to specify startup order or dependencies. Groups are still reusab= le although not all applications will use all groups, some groups might be = specifically used by certain applications only, others not. The advantage, = =C2=A0at least I think, =C2=A0we see with separating dependencies from subs= cription related information is that IMHO it will be less confusing to unde= rstand and also it will make for a cleaner implementation. At the end, eith= er approach will work. Either way should be fine with me,

> =C2=A0

> Regards

> =C2=A0

> Martin

> =C2=A0

> 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; Shaheed= ur Haque (shahhaqu); Lakmal Warusawithana (lakmal@wso2.com)

> Subject: Re: Summary of Composite Application Defi= nition with Reference to Deployed Service Groups discussion

> =C2=A0

> Hi Martin,

> =C2=A0

>

> On Tue, Jul 15, 2014 at 5:15 PM, Martin Eppel (mep= pel) <meppel@cisco= .com> wrote:

> I agree with splitting it =C2=A0into sub groups an= d cartridges =E2=80=93 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 depen= dency 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 th= e 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 Applicatio= n Definition so that cartridges are groups can be started in a particular o= rder.

> =C2=A0

> In your example below the startup sequence would b= e (?) :

> =C2=A0

> cartridge.tomcat -> group.mygroup2 -> cartri= dge.php -> group.group1 -> mygroup1.mysql

> =C2=A0

> but I think the same could be modeled if we specif= y in group2 the following dependency:

> =C2=A0

> "dependencies": {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "s= tartupOrder": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "start": "group.g= roup1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "after": "cartrid= ge.php"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 },

> {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "start": "cartrid= ge.php=E2=80=9D,

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "after": " cartri= dge.tomcat "=C2=A0 // has no dependency, can be started immediatly

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 }

> This would be fine if the Group 2 had the cartridg= e 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 defi= nitions is to make them re-usable.

> =C2=A0

> =C2=A0

> I just would like to keep dependency and subscript= ion information separate and don=E2=80=99t have to specify any dependency i= n the composite application, WDYT ?

> As I mentioned above, the specifying dependencies = in a Composite App is not mandatory. The user can create a Application Defi= nition without it. IMHO there can be some information in Groups which can b= e overridden in Subscription time. As an example, in future, we could allow= to define deployment and autoscaling policies in the group definition itse= lf, and allow users to override those if they prefer at subscription time, = by specifying different policies.

> =C2=A0

> Thanks

> =C2=A0

> Martin

> =C2=A0

> 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; Shahee= dur Haque (shahhaqu); Lakmal Warusawithana (lakmal@wso2.com)

> Subject: Re: Summary of Composite Application Defi= nition with Reference to Deployed Service Groups discussion

> =C2=A0

> 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 val= idating the Composite App Definition. Else, we need to separately check whe= ther this is a group/cartridge,=C2=A0 and we can avoid that by specifying t= hat 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. Therefor= e, I added a Dependency section as well.

>

> Please note I have referred to Cartridge Level Sub= scriptions as subscribables.

>

> Please find two sample Groups [1, 2] and a sample = Composite App Definition [3]. WDYT?

>

> [1].

> {

> =C2=A0=C2=A0=C2=A0 "name": "group2&= quot;,

> =C2=A0=C2=A0=C2=A0 "subGroups": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "g= roup1"

> =C2=A0=C2=A0=C2=A0 ],

> =C2=A0=C2=A0=C2=A0 "cartridges": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "p= hp"

> =C2=A0=C2=A0=C2=A0 ],

> =C2=A0=C2=A0=C2=A0 "dependencies": {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "s= tartupOrder": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "start": "group.g= roup1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "after": "cartrid= ge.php"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 }

> =C2=A0=C2=A0=C2=A0 ],

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "k= illBehaviour": "kill-dependents"

> =C2=A0=C2=A0=C2=A0 }

> }

>

> [2].

> {

> =C2=A0=C2=A0=C2=A0 "name": "group1&= quot;,

> =C2=A0=C2=A0=C2=A0 "cartridges": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "m= ysql"

> =C2=A0=C2=A0=C2=A0 ],

> =C2=A0=C2=A0=C2=A0 "dependencies": {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "k= illBehaviour": "kill-none"

> =C2=A0=C2=A0=C2=A0 }

> }

>

>

> [3].

> {

> =C2=A0 "applicationId": "test_app&q= uot;,

> =C2=A0 "components": {

> =C2=A0=C2=A0=C2=A0 "groups": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "n= ame": "group2",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "a= lias": "mygroup2",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "d= eploymentPolicy": "dep_policy_group2",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "a= utoscalingPolicy": "autoscale_policy_group2",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "s= ubscribables": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 "type": "php",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 "alias": "mygroup2.php",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 }

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ],

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "s= ubGroup": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 "name": "group1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 "alias": "mygroup1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 }

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ],

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "n= ame": "group1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "a= lias": "mygroup1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "d= eploymentPolicy": "dep_policy_group1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "a= utoscalingPolicy": "autoscale_policy_group1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "s= ubscribables": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 "type": "mysql",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 "alias": "mygroup1.mysql",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 },

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ],

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

> =C2=A0=C2=A0=C2=A0 ],

> =C2=A0=C2=A0=C2=A0 "subscribables": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "t= ype": "tomcat",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "a= lias": "mytomcat"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

> =C2=A0=C2=A0=C2=A0 ],

> =C2=A0=C2=A0=C2=A0 "dependencies": {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "startupOrder&= quot;: [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "start": "group.mygroup2",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "after": "cartridge.tomcat"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ],

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "killBehaviour= ": "kill-dependents"

> =C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0

> =C2=A0 },

> =C2=A0 "subscribableInformation": [

> =C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "alias": = "mygroup2.mysql",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "deploymentPol= icy": "dep_policy_mysql",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "autoscalingPo= licy": "autoscale_policy_mysql"

> =C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "alias": = "mygroup2.php",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "deploymentPol= icy": "dep_policy_php",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "autoscalingPo= licy": "autoscale_policy_php",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "repoURL"= : "www.mygi= t.com/php.git",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "privateRepo&q= uot;: "true",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "repoUsername&= quot;: "admin",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "repoPassword&= quot;: "xxxx"

> =C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "alias": = "mytomcat",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "deploymentPol= icy": "dep_policy_tomcat",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "autoscalingPo= licy": "autoscale_policy_tomcat",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "repoURL"= : "www.m= ygit.com/tomcat.git",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "privateRepo&q= uot;: "false",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "repoUsername&= quot;: "admin",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "repoPassword&= quot;: "yyyy"

> =C2=A0=C2=A0=C2=A0 }

> =C2=A0 ]

> }

> =C2=A0

>

> On Tue, Jul 15, 2014 at 2:18 PM, Martin Eppel (mep= pel) <meppel@cisco= .com> wrote:

> Hi Udara,

> =C2=A0

> I think we can flatten out the json structure and = =E2=80=9Csimplify=E2=80=9D a little bit more:

> =C2=A0

> 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. Th= e composite application has 2 sections, groups and cartridges, each specifi= es the subscription instances of respective groups and cartridges and links= them together in the subscribales section (list of subscribed group member= s: nested group subscription instances and cartridge subscription instances= ) of the group subscription.

> =C2=A0

> For instance, in the example below, I define a tem= plate for group1, group2 and group3. Group2 and group3 each have a dependen= cy 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 deploy= ment policies and auto scaling policies). The subscription instance of grou= p2 (alias =E2=80=9Cmygroup2=E2=80=9D) refers to a subscription instance of = group1 with alias mygroup1 while =C2=A0the subscription instance of group3 = refers to a subscription instance of group1 with an alias of mygroup1b. gro= up1 subscriptions mygroup1 and mygroup1b each define different auto scaling= / deployment policy.

> =C2=A0

> During deployment =C2=A0we take the subscription i= nstances and populate the =E2=80=9Cgeneric=E2=80=9D dependency model (based= on the serviceGroups) with specific subscription instances

> =C2=A0

> What do you think ?

> =C2=A0

> Thanks

> =C2=A0

> Martin

> =C2=A0

> =C2=A0

> [1a]

> {

> =C2=A0=C2=A0=C2=A0 "name": "group1&= quot;,

> =C2=A0=C2=A0=C2=A0 "cartridges": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "m= ysql", "mongoDB"

> =C2=A0=C2=A0=C2=A0 ],

> =C2=A0=C2=A0=C2=A0 "dependencies": {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "k= illBehaviour": "kill-none"

> =C2=A0=C2=A0=C2=A0 }

> }

> =C2=A0

> [1b]

> {

> =C2=A0=C2=A0=C2=A0 "name": "group2&= quot;,

> =C2=A0=C2=A0=C2=A0 "subGroups": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "g= roup1"

> =C2=A0=C2=A0=C2=A0 ],

> =C2=A0=C2=A0=C2=A0 "cartridges": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "p= hp", "app1"

> =C2=A0=C2=A0=C2=A0 ],

> =C2=A0=C2=A0=C2=A0 "dependencies": {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "s= tartupOrder": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "start": "cartrid= ge.php",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "after": "group.g= roup1"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "start": "cartrid= ge.app1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "after": "cartrid= ge.php"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 }

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ]= ,

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "k= illBehaviour": "kill-dependents"

> =C2=A0=C2=A0=C2=A0=C2=A0}

> }

> =C2=A0

> [1c]

> {

> =C2=A0=C2=A0=C2=A0 "name": "group3&= quot;,

> =C2=A0=C2=A0 =C2=A0"subGroups": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "g= roup1"

> =C2=A0=C2=A0=C2=A0 ],

> =C2=A0=C2=A0=C2=A0 "cartridges": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "a= pp2"

> =C2=A0=C2=A0=C2=A0 ],

> =C2=A0=C2=A0=C2=A0 "dependencies": {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "s= tartupOrder": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "start": "cartrid= ge.app2",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "after": "group.g= roup1"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 }

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ]= ,

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "k= illBehaviour": "kill-dependents"

> =C2=A0=C2=A0=C2=A0=C2=A0}

> }

> [2]

> {

> =C2=A0 "applicationId": "test_app&q= uot;,

> =C2=A0 "alias": "myapp1",

> =C2=A0 "components": [

> =C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "group": = "group1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "alias": = "mygroup1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "subscribables= ": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "m= ygroup1.mysql", "mygroup1.mongoDB"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ]

> =C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "group": = "group1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "alias": = "mygroup1b",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "subscribables= ": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "m= ygroup1.mysql", "mygroup1.mongoDB"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ]

> =C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "group": = "group2",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "alias": = "mygroup2",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "subscribables= ": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { "= ;mygroup1", "mygroup2.php", "mygroup2.app1"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ]

> =C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "group": = "group3",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "alias": = "mygroup3",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "subscribables= ": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "mygroup1b", "mygroup3.= app1"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ]

> =C2=A0=C2=A0=C2=A0 }

> =C2=A0=C2=A0=C2=A0

> =C2=A0=C2=A0],

> =C2=A0 "groups": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "group": = "group1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "alias": = "mygroup1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "deploymentPol= icy": "dep_policy_group1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "autoscalingPo= licy": "autoscale_policy_group1"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "group": = "group1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "alias": = "mygroup1b",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "deploymentPol= icy": "dep_policy_group1b",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "autoscalingPo= licy": "autoscale_policy_group1b"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "group": = "group2",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "alias": = "mygroup2",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "deploymentPol= icy": "dep_policy_group2",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "autoscalingPo= licy": "autoscale_policy_group2"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "group": = "group3",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "alias": = "mygroup3",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "deploymentPol= icy": "dep_policy_group3",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "autoscalingPo= licy": "autoscale_policy_group3"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

> =C2=A0 ],

> =C2=A0

> =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0"cartridges&qu= ot;: [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"type": &q= uot;mysql",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"alias": &= quot;mygroup1.mysql",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"deploymentPoli= cy": "dep_policy_mysql",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"autoscalingPol= icy": "autoscale_policy_mysql"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"type&qu= ot;: "mongoDB",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"alias&qu= ot;: "mygroup1.mongoDB",

> =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"deploym= entPolicy": "dep_policy_mongoDB",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"autoscal= ingPolicy": "autoscale_policy_mongoDB",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"repoURL":= "www.m= ygit.com/mongoDB.git",

> =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0"privateRepo&q= uot;: "true",

> =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0"repoUsername&= quot;: "admin",

> =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"repoPas= sword": "xxxx"

> =C2=A0=C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "type": &= quot;tomcat",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "alias": = "mytomcat",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "deploymentPol= icy": "dep_policy_tomcat",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "autoscalingPo= licy": "autoscale_policy_tomcat",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "repoURL"= : "www.m= ygit.com/tomcat.git",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "privateRepo&q= uot;: "false",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "repoUsername&= quot;: "admin",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "repoPassword&= quot;: "yyyy"

> =C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "type": "php&quo= t;,

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "alias": "mygrou= p2.php",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "deploymentPolicy": &= quot;dep_policy_php",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "autoscalingPolicy": = "autoscale_policy_php"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "type": "app1&qu= ot;,

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "alias": "mygrou= p2.app1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "deploymentPolicy": &= quot;dep_policy_app1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "autoscalingPolicy": = "autoscale_policy_app1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "repoURL": "www.mygit.com/app1.= git",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "privateRepo": "= true",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "repoUsername": "= ;admin",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "repoPassword": "= ;xxxx"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "type": "app1&qu= ot;,

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "alias": "mygrou= p3.app1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "deploymentPolicy": &= quot;dep_policy_app1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "autoscalingPolicy": = "autoscale_policy_app1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "repoURL": "www.mygit.com/app1.= git",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "privateRepo": "= true",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "repoUsername": "= ;admin",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "repoPassword": "= ;xxxx"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

> =C2=A0 ]

> }

> =C2=A0

> 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 (s= hahhaqu); Lakmal Warusawithana (lakmal@wso2.com)

> Subject: Re: Summary of Composite Application Defi= nition with Reference to Deployed Service Groups discussion

> =C2=A0

> =C2=A0

> I am refering to the composite app json you have p= asted 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 questio= n how to specify subscribable details for the cartridges of group2. If we a= re to define them nested, I think json definition will become complex.

> My suggestion is to define those refering groups a= s sub groups with an alias. Then later we define the subscribable details w= ith this alias.

> Assume that group2 has mongoDb cartridge defined a= nd group1 refers to group2. In components we specify the group2 as below

> =C2=A0

> "subGroup": [

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "na= me": "group2",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "al= ias": "mygroup2",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ],

> =C2=A0

> We add alias "mygroup2" to refer to the = group2. Then at subscribableInformation section we provide sunscription det= ails for the group2 mongoDb cartridge.

> =C2=A0

> =C2=A0 "subscribableInformation": [

> =C2=A0 =C2=A0 {

> =C2=A0 =C2=A0 =C2=A0 "alias": "mygr= oup2.mongo",

> =C2=A0 =C2=A0 =C2=A0 "deploymentPolicy":= "dep_policy_mongo",

> =C2=A0 =C2=A0 =C2=A0 "autoscalingPolicy"= : "autoscale_mongo"

> =C2=A0 =C2=A0 },

> =C2=A0

> I have pasted the whole json below. Let me know yo= ur feedback

> =C2=A0

> {

> =C2=A0 "applicationId": "test_app&q= uot;,

> =C2=A0 "alias": "myapp1",

> =C2=A0 "components": {

> =C2=A0 =C2=A0 "groups": [

> =C2=A0 =C2=A0 =C2=A0 {

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "name": &quo= t;group1",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "alias": &qu= ot;mygroup1",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "deploymentPolicy= ": "dep_policy_group1",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "autoscalingPolic= y": "autoscale_policy_group1",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "subscribables&qu= ot;: [

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "ty= pe": "mysql",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "al= ias": "mygroup1.mysql",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "ty= pe": "php",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "al= ias": "mygroup1.php"

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ],

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "subGroup": = [

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "na= me": "group2",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "al= ias": "mygroup2",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ],

> =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0

> =C2=A0 =C2=A0 =C2=A0 },

> =C2=A0 =C2=A0 =C2=A0 {

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "name": &quo= t;group2",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "alias": &qu= ot;mygroup2",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "deploymentPolicy= ": "dep_policy_group2",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "autoscalingPolic= y": "autoscale_policy_group2",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "subscribables&qu= ot;: [

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "ty= pe": "mongo",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "al= ias": "mygroup2.mongo",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ],

> =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0

> =C2=A0 =C2=A0 =C2=A0 },

> =C2=A0 =C2=A0 =C2=A0=C2=A0

> =C2=A0 =C2=A0 ],

> =C2=A0 =C2=A0 "subscribables": [

> =C2=A0 =C2=A0 =C2=A0 {

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type": &quo= t;tomcat",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "alias": &qu= ot;mytomcat"

> =C2=A0 =C2=A0 =C2=A0 }

> =C2=A0 =C2=A0 ],

> =C2=A0 =C2=A0 "dependencies": {

> =C2=A0 =C2=A0 =C2=A0 "startupOrder": [

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 {

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "start&quo= t;: "group.mygroup1",

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "after&quo= t;: "cartridge.tomcat"

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

> =C2=A0 =C2=A0 =C2=A0 ],

> =C2=A0 =C2=A0 =C2=A0 "killBehaviour": &q= uot;kill-dependents"

> =C2=A0 =C2=A0 },

> =C2=A0 =C2=A0=C2=A0

> =C2=A0 },

> =C2=A0 "subscribableInformation": [

> =C2=A0 =C2=A0 {

> =C2=A0 =C2=A0 =C2=A0 "alias": "mygr= oup1.mysql",

> =C2=A0 =C2=A0 =C2=A0 "deploymentPolicy":= "dep_policy_mysql",

> =C2=A0 =C2=A0 =C2=A0 "autoscalingPolicy"= : "autoscale_policy_mysql"

> =C2=A0 =C2=A0 },

> =C2=A0 =C2=A0 {

> =C2=A0 =C2=A0 =C2=A0 "alias": "mygr= oup2.mongo",

> =C2=A0 =C2=A0 =C2=A0 "deploymentPolicy":= "dep_policy_mongo",

> =C2=A0 =C2=A0 =C2=A0 "autoscalingPolicy"= : "autoscale_mongo"

> =C2=A0 =C2=A0 },

> =C2=A0 =C2=A0 {

> =C2=A0 =C2=A0 =C2=A0 "alias": "mygr= oup1.php",

> =C2=A0 =C2=A0 =C2=A0 "deploymentPolicy":= "dep_policy_php",

> =C2=A0 =C2=A0 =C2=A0 "autoscalingPolicy"= : "autoscale_policy_php",

> =C2=A0 =C2=A0 =C2=A0 "repoURL": "www.mygit.com/php.= git",

> =C2=A0 =C2=A0 =C2=A0 "privateRepo": &quo= t;true",

> =C2=A0 =C2=A0 =C2=A0 "repoUsername": &qu= ot;admin",

> =C2=A0 =C2=A0 =C2=A0 "repoPassword": &qu= ot;xxxx"

> =C2=A0 =C2=A0 },

> =C2=A0 =C2=A0 {

> =C2=A0 =C2=A0 =C2=A0 "alias": "myto= mcat",

> =C2=A0 =C2=A0 =C2=A0 "deploymentPolicy":= "dep_policy_tomcat",

> =C2=A0 =C2=A0 =C2=A0 "autoscalingPolicy"= : "autoscale_policy_tomcat",

> =C2=A0 =C2=A0 =C2=A0 "repoURL": "www.mygit.com/t= omcat.git",

> =C2=A0 =C2=A0 =C2=A0 "privateRepo": &quo= t;false",

> =C2=A0 =C2=A0 =C2=A0 "repoUsername": &qu= ot;admin",

> =C2=A0 =C2=A0 =C2=A0 "repoPassword": &qu= ot;yyyy"

> =C2=A0 =C2=A0 }

> =C2=A0 ]

> }

> =C2=A0

>

> On Sun, Jul 13, 2014 at 7:44 PM, Isuru Haththotuwa= <isuruh@apache.o= rg> wrote:

> =C2=A0

> =C2=A0

>

> On Fri, Jul 11, 2014 at 5:25 PM, Martin Eppel (mep= pel) <meppel@cisco= .com> wrote:

> Hi Udara,

> =C2=A0

> The changes look good, one =C2=A0comment:

> =C2=A0

> ComponentDefinition.java :

> I think dependencies need to be removed from Compo= nentDefinition =C2=A0(=E2=80=9Cpublic ConfigDependencies dependencies;=E2= =80=9D), should be describes as part of the ServiceGroup, what do you think= ?

> +1.=C2=A0

> =C2=A0

> Thanks

> =C2=A0

> Martin

> =C2=A0

> =C2=A0

> =C2=A0

> 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 Haththo= tuwa (isuruh@wso2.com<= /a>); Lakmal Warusawithana (lakmal@wso2.com)

>

> Subject: Re: Summary of Composite Application Defi= nition with Reference to Deployed Service Groups discussion

> =C2=A0

> Hi Martin,

> =C2=A0

> Change is based on=C2=A0remotes/origin/4.0.0-group= ing branch.

> =C2=A0

>

> On Fri, Jul 11, 2014 at 2:16 PM, Martin Eppel (mep= pel) <meppel@cisco= .com> wrote:

> Hi Udara,

> =C2=A0

> Which branch are your changes based on ?

> =C2=A0

> From: Udara Liyanage [mailto:udara@wso2.com]

> Sent: Thursday, July 10, 2014 11:39 PM

> To: dev

> Cc: Martin Eppel (meppel); Shaheedur Haque (shahha= qu); Isuru Haththotuwa (isuruh@wso2.com); Lakmal Warusawithana (lakmal@wso2.com)

>

> Subject: Re: Summary of Composite Application Defi= nition with Reference to Deployed Service Groups discussion

> =C2=A0

> Hi Reka and Martin,

> =C2=A0

> I made changes according to the last json format s= ent by Martin. I have attached the diff before commiting. Could someone hav= e a glance.

> Please note that I did not consider the scenario o= f nested group scenario for simplicity.

> =C2=A0

>

> On Wed, Jul 9, 2014 at 1:39 PM, Reka Thirunavukkar= asu <reka@wso2.com> wrote:

> Thanks Martin..

> =C2=A0

>

> On Wed, Jul 9, 2014 at 1:34 PM, Martin Eppel (mepp= el) <meppel@cisco.= com> wrote:

> Hi Reka,

> =C2=A0

> Actually I just copied the example from one of the= previous emails (Imesh and Isuru=E2=80=99s emails) as examples.

> =C2=A0

> But I think you are right, the composite applicati= on defines these parameters (in the subscribable section) for each cartridg= e or sub group as defined in the service group. From example [1] in group1 = it =C2=A0lists 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...

> =C2=A0

> Thanks

> =C2=A0

> Martin

> =C2=A0

> 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@w= so2.com); Lakmal Warusawithana (lakmal@wso2.com)

> Subject: Re: Summary of Composite Application Defi= nition with Reference to Deployed Service Groups discussion

> =C2=A0

> Hi Martin,

>

> Thanks for the summary...I have a small doubt with= Composite Application Model. It is mentioned as below..

> =C2=A0

>

> On Tue, Jul 8, 2014 at 8:07 PM, Martin Eppel (mepp= el) <meppel@cisco.= com> wrote:

> I browsed over the previously exchanged emails, co= mpiled and summarized it below (please correct me when my understanding is = incorrect).

> =C2=A0

> + service Groups definitions are deployed independ= ently of each other (similar to deploying a cartridge or policy)

> =C2=A0=C2=A0 (something along the lines like =E2= =80=9Cdeploy-service-group service-group- definition.json=E2=80=9D, for sam= ple definition see [1], [2])

> + service Groups are named and can be referenced i= n a composite application

> + generally, service groups logically groups other= service group definitions and cartridge types and describes their interdep= endencies

> + dependencies are described as part of the servic= e group definition

> + For the format and examples of a service group s= ee [1], [2] below

> + other characteristics of service groups like aut= o-scaling, deployment restrictions =C2=A0are describes as part of the compo= site application

> =C2=A0

> =C2=A0

> + Composite application is deployed independent of= service groups

> + composite application references (already deploy= ed) service groups and cartridges

> + provides required subscription and deployment = =C2=A0information 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 a= lso by assigning characteristics like auto-scaling, deployment policy, etc = =E2=80=A6 which are specific for the application (for instance another appl= ication could define other deployment policies for the same service group d= efinition)

> + composite application format and example see [3]= =C2=A0

> In [3] as you have referenced "group1", = then don't we need to specify the characteristics against the group/car= tridge type which used in "group1" ? In that case, we need to spe= cify only for mongoDB as well as group1 based characteristics? Please corre= ct me, if i'm wrong..

>

> Thanks,

> Reka

> =C2=A0

> + N number of applications will be supported ?

> =C2=A0

> =C2=A0

> =C2=A0

> {

> =C2=A0=C2=A0=C2=A0 "name": "group1&= quot;,

> =C2=A0=C2=A0=C2=A0 "cartridges": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "m= ysql", "mongoDB"

> =C2=A0=C2=A0=C2=A0 ],

> =C2=A0=C2=A0=C2=A0 "dependencies": {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "k= illBehaviour": "kill-none"

> =C2=A0=C2=A0=C2=A0 }

> }

> =C2=A0

> [2].

> {

> =C2=A0=C2=A0=C2=A0 "name": "group2&= quot;,

> =C2=A0=C2=A0=C2=A0 "subGroups": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "g= roup1"

> =C2=A0=C2=A0=C2=A0 ],

> =C2=A0=C2=A0=C2=A0 "cartridges": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "p= hp"

> =C2=A0=C2=A0=C2=A0 ],

> =C2=A0=C2=A0=C2=A0 "dependencies": {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "s= tartupOrder": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "start": "group.g= roup1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "after": "cartrid= ge.php"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 }

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ]= ,

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "k= illBehaviour": "kill-dependents"

> =C2=A0

> =C2=A0=C2=A0=C2=A0 }

> }

> =C2=A0

> [3]

> =C2=A0

> {

> =C2=A0 "applicationId": "test_app&q= uot;,

> =C2=A0 "alias": "myapp1",

> =C2=A0 "components": [

> =C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "group": = "group1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "alias": = "mygroup1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "deploymentPol= icy": "dep_policy_group1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "autoscalingPo= licy": "autoscale_policy_group1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "subscribables= ": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "type": "mysql",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "alias": "mygroup1.mysql",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "deploymentPolicy": "dep_policy_mysql",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "autoscalingPolicy": "autoscale_policy_mysql"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "type": "php",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "alias": "mygroup1.php",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "deploymentPolicy": "dep_policy_php",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "autoscalingPolicy": "autoscale_policy_php",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "repoURL": "www.mygit.com/php.git",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "privateRepo": "true",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "repoUsername": "admin",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "repoPassword": "xxxx"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ]

> =C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0

> =C2=A0=C2=A0],

> =C2=A0 "cartridges": [

> =C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "type": &= quot;tomcat",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "alias": = "mytomcat",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "deploymentPol= icy": "dep_policy_tomcat",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "autoscalingPo= licy": "autoscale_policy_tomcat",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "repoURL"= : "www.m= ygit.com/tomcat.git",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "privateRepo&q= uot;: "false",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "repoUsername&= quot;: "admin",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "repoPassword&= quot;: "yyyy"

> =C2=A0=C2=A0=C2=A0 }

> =C2=A0 ]

> }

> =C2=A0

> 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

> =C2=A0

> Hi Isuru,

> =C2=A0

> See below=E2=80=A6

> =C2=A0

> 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 Ref= erence to Deployed Service Groups

> =C2=A0

> Hi all,

>

> Since we have the Service Group persistence now, w= e can change the Composite Application to refer the previously deployed Ser= vice Groups [1]. WDYT?

>

> [srh] I think I missed groups being deployed/persi= sted separately. Does the =E2=80=9Csubscription=E2=80=9D information (meani= ng deployment and autoscaling only for a group, everything for a cartridge)= , get persisted with each group?

> =C2=A0

> =C2=A0

> The Subscribable section will carry subscription l= evel 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. Al= so 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].

> =C2=A0

> [srh] Some questions:

> =C2=A0

> 1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I think I don=E2= =80=99t 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 impli= es.

>

> 2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In [1] you don=E2= =80=99t show nested groups. How should those be represented? Or are they no= t needed because groups are being deployed/persisted separately, and this a= pplication only specifies the top level groups/cartridges and their respect= ive =E2=80=9Csubscriptions=E2=80=9D?

>

> =C2=A0

> I=E2=80=99m a little uneasy about the inline model= of the =E2=80=9Csubscription=E2=80=9D information. I tend to think that th= is can be factored out (though it is not the end of the world to keep it in= line) subject to my understanding of questions 1 and 2.

> =C2=A0

> BTW, I saw this email after I responded to [2] J

> =C2=A0

> Thanks, Shaheed

>

> [1].

> {

> =C2=A0 "applicationId": "test_app&q= uot;,

> =C2=A0 "alias": "myapp1",

> =C2=A0 "components": [

> =C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "group": = "group1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "alias": = "mygroup1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "deploymentPol= icy": "dep_policy_group1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "autoscalingPo= licy": "autoscale_policy_group1",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "subscribables= ": [

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "type": "mysql",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "alias": "mygroup1.mysql",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "deploymentPolicy": "dep_policy_mysql",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "autoscalingPolicy": "autoscale_policy_mysql"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "type": "php",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "alias": "mygroup1.php",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "deploymentPolicy": "dep_policy_php",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "autoscalingPolicy": "autoscale_policy_php",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "repoURL": "www.mygit.com/php.git",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "privateRepo": "true",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "repoUsername": "admin",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "repoPassword": "xxxx"

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ]

> =C2=A0=C2=A0=C2=A0 },

> =C2=A0=C2=A0=C2=A0

> =C2=A0 ],

> =C2=A0 "cartridges": [

> =C2=A0=C2=A0=C2=A0 {

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "type": &= quot;tomcat",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "alias": = "mytomcat",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "deploymentPol= icy": "dep_policy_tomcat",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "autoscalingPo= licy": "autoscale_policy_tomcat",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "repoURL"= : "www.m= ygit.com/tomcat.git",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "privateRepo&q= uot;: "false",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "repoUsername&= quot;: "admin",

> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "repoPassword&= quot;: "yyyy"

> =C2=A0=C2=A0=C2=A0 }

> =C2=A0 ]

> }

> =C2=A0

>

> [2]. Composite Application Deployment and Subscrip= tion - 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

> =C2=A0

>

>

>

>

> --

> Reka Thirunavukkarasu

> Senior Software Engineer,

> WSO2, Inc.:http://wso2.com,

> Mobile: +94776442007

> =C2=A0

>

>

>

> =C2=A0

> --

>

> Udara Liyanage

> Software Engineer

> WSO2, Inc.:=C2=A0http://wso2.com

> lean. enterprise. middleware

>

> web: http://udaraliyanage.wordpress.com

> phone:=C2=A0+94 71 443 6897

>

>

> =C2=A0

> --

>

> Udara Liyanage

> Software Engineer

> WSO2, Inc.:=C2=A0http://wso2.com

> lean. enterprise. middleware

>

> web: http://udaraliyanage.wordpress.com

> phone:=C2=A0+94 71 443 6897

>

> --

> Thanks and Regards,

>

> Isuru H.

> +94 716 358 048

>

> =C2=A0

>

>

>

> =C2=A0

> --

>

> Udara Liyanage

> Software Engineer

> WSO2, Inc.:=C2=A0http://wso2.com

> lean. enterprise. middleware

>

> web: http://udaraliyanage.wordpress.com

> phone:=C2=A0+94 71 443 6897

>

> --

>

> Thanks and Regards,

>

> Isuru H.

>

> +94 716 358 048

>

> --

>

> Thanks and Regards,

>

> Isuru H.

> +94 716 358 048

>

>

>

>

>

>

--

<= div>Thanks and Regards,

Isuru H.
+94 716 358 048




--001a11c3c6d21051f004fea1856d--