Hi Reka, Thanks for the reply, it was very helpful. I think I am getting the hang of it, I created an application with nested groups (group5 depends on group6 depends on group7, each group with a cartridge c1) and it seems to work as expected (still need to resolve issues with my cartridges going active).
One observation, as I made some mistakes in my previous application definition I noticed that we don’t cross check the subgroups defined in the application definition against the sub groups defined in the group definition. Making a mistake can lead to some unexpected behavior. I think we should add that in the longer term to avoid unnecessary confusion, Thanks Martin From: Reka Thirunavukkarasu [mailto:[email protected]] Sent: Wednesday, October 15, 2014 2:04 AM To: Martin Eppel (meppel) Cc: [email protected]; Isuru Haththotuwa; Udara Liyanage Subject: Re: [Grouping][testing] How to model nested dependencies ? Hi Martin, I understand that our application definition needs to be improved more to eliminate the confusion. As of now, we expect the user to define the top level groups as well as sub groups under the groups section of an application which makes you the confusion. Let's say that you are going to subscribe to group2 and tomcat in your application. But group2 has a subgroup called group1 and php2 cartridge. goup1 has php1 cartridge. In that case, your application should use group2 and tomcat as in top level. When you define group2 as top level, inside that you have to mention the alias for the sub groups and the associated cartridges for goup2 as below: "components": { "groups": [ { "name": "group2", "alias": "mygroup2", "deploymentPolicy": "deployment_policy_1", "autoscalingPolicy": "autoscale_policy_1", "subscribables": [ { "type": "tomcat", "alias": "mygroup2tomcat" } ], "subGroups": [ { "name": "group1", "alias": "mygroup1" } ] }, { "name": "group1", "alias": "mygroup1", "deploymentPolicy": "dep_policy_group1", "autoscalingPolicy": "autoscale_policy_group1", "subscribables": [ { "type": "tomcat", "alias": "mygroup1tomcat" }, { "type": "tomcat1", "alias": "mygroup1tomcat1" } ] } ], "subscribables": [ { "type": "tomcat", "alias": "mytomcat" } ], "dependencies": { "startupOrders": [ "group.mygroup2,cartridge.mytomcat" ], "killBehaviour": "kill-dependents" } Then using the given alias for sub groups as above, you will need to create group for group1 with the same alias which defined inside group2 as i highlighted in purple. In that case, group1 is not a top level rather it will be used by group2 as group2 has the same alias of group1. The highlighted ones in blue are the top level elements which require startupOrders in the application. For group1, since it is a subgroup, we expect to have the startupOrder in the group1's group definition itself. Does above explanation solve your issue? You can refer the guide which we have attached in "[Announce] Apache Stratos Service Grouping Developer Preview - 2 is Ready". Please share us, if you think in any other way that we can improve this application definition. In the mean time, we will also go through and update on how we can improve this. Thanks, Reka On Wed, Oct 15, 2014 at 7:32 AM, Martin Eppel (meppel) <[email protected]<mailto:[email protected]>> wrote: Reka, I am still having trouble with the model. Actually, I was wondering if you could, for example based on the example you sent out previously (I attached the json) or some other suitable model describe which cartridge, group gets started up when (pretty much explain how the dependencies are resolved and what states a cartridge or groups has to be) ? I think it would be really helpful to understand the model. I f this is not possible can we setup a meeting to discuss it ? Thanks Martin From: Martin Eppel (meppel) Sent: Tuesday, October 14, 2014 1:15 PM To: Reka Thirunavukkarasu Cc: [email protected]<mailto:[email protected]>; Isuru Haththotuwa; Udara Liyanage Subject: RE: [Grouping][testing] How to model nested dependencies ? Reka, I think the issue is I don’t understand what goes into the “component” and dependencies section of the application definition. My current understanding is that all groups in an application have to be listed in the “components” section – but it also seems to make them all to top level groups. One of the reasons I choose the example below is that I don’t have a clear understanding on how to model the top level group (group1) versus the sub groups (group2, group3). In the example below I tried to specify group1 as top level group and group2, group3 as sub groups (group2 a sub group of group1 and group3 a subgroup of group3). But it seems I have to list them all in the component section of the application to assign group alias (if I don’t list a group in the component section and exception is thrown). But, once listed in the component section it makes them all top level groups and what happens to the dependencies described in the sub groups ? Actually, right know I am even more confused than before how to model sub groups vs. top level groups and how to model respective dependencies. For example, if I want to have only one top level group and many sub groups with dependencies among the sub groups, how would I model it: Using my initial example, where group1 would be the top level group and group2 and group3 would be sub groups, how would the application definition look like and how the group definitions ? Thanks Martin From: Reka Thirunavukkarasu [mailto:[email protected]] Sent: Monday, October 13, 2014 10:56 PM To: Martin Eppel (meppel) Cc: [email protected]<mailto:[email protected]>; Isuru Haththotuwa; Udara Liyanage Subject: Re: [Grouping][testing] How to model nested dependencies ? Hi Martin, As i mentioned in the other mail, you can define startup order for top level groups/cartridges in the application and you can define startup order in the group definition for group's subgroups/cartridges. In your case, i'm not sure why are you trying with nested group definition. Group1 (c1) should start up after group2, group2 (c2) should start up after group3 (c3) The above is a linear relationship where we can say a startup order as "group.group3, group.group2, group.group1". So that group3 will come up first. Then group2 and group3 will come up accordingly. But if you would like to test nested groups, then you can organise the groups as below: group1 --> c1, c2 where startup order is "c1,c2" group2 --> c1, c3 (no startup order means both will come up in parallel) group3 --> group2, c2 where startup order is "group2, c2" group4 --> group1, c3 where startup order is "group1, c3" application --> group3, group4, c1, c3 where startup order is "group3, c1", "group3, group4" If you write up group definition and application definition for the above mentioned relationship, you can see how these nested groups are brought up as well as you can see some groups/cartridges will be brought up in parallel as well. Thanks, Reka -- Reka Thirunavukkarasu Senior Software Engineer, WSO2, Inc.:http://wso2.com, Mobile: +94776442007
group6c.json
Description: group6c.json
group7c.json
Description: group7c.json
application_test_app5c.json
Description: application_test_app5c.json
group5c.json
Description: group5c.json
