Hi On Thu, Oct 16, 2014 at 4:10 AM, Martin Eppel (meppel) <[email protected]> wrote:
> 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). > Great.. 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, > Sure..We will work on these improvements.. Thanks, Reka > > > 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]> > 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]; 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] <[email protected]>] > *Sent:* Monday, October 13, 2014 10:56 PM > *To:* Martin Eppel (meppel) > *Cc:* [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 > > > -- Reka Thirunavukkarasu Senior Software Engineer, WSO2, Inc.:http://wso2.com, Mobile: +94776442007
