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
