You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by "Martin Eppel (meppel)" <me...@cisco.com> on 2014/10/14 02:47:56 UTC
[Grouping][testing] How to model nested dependencies ?
Hi Reka, Isuru,
I was trying to model a nested dependency utilizing the dependency section in the group definition but I am unsure how to do it.
For example, I define a group1, group2 and group3
Group3 is a subgroup of group2,
Group2 is a sub group of group1
Group7 has a cartridge c3
Group6 has a cartridge c2
Group5 has a cartridge c1
Group1 (c1) should start up after group2, group2 (c2) should start up after group3 (c3)
The only way to model the dependencies seemed to be to model it in the dependency section in the application definition:
"dependencies": {
"startupOrders": [
"cartridge.c3alias51,group.group6alias",
"group.group5alias,group.group6alias"
],
"killBehaviour": "kill-dependents"
}
However, deploying the application didn’t start any cartridges (VMs), not even the one without dependency (in group7, alias: “c3alias51”) ? Did I specify the dependencies wrong or something else in the app / group defs ?
I attached the group / application definition to the email,
Thanks
Martin
From: Martin Eppel (meppel)
Sent: Monday, October 13, 2014 4:37 PM
To: Reka Thirunavukkarasu; Isuru Haththotuwa
Cc: dev; Udara Liyanage
Subject: RE: [Grouping][testing] Hierarchical Monitors with Composite Application
Hi Reka,
I run a scenario similar to yours (see attached application json (application_test_app5a, group5.json, group6.json) :
Deployed groups :
group5: cartridges: [c1, c2], subgroups: [group6]
group6: cartridges: [c2], subgroups: []
Deployed Application :
Dependencies: startupOrders: ["cartridge.c1xxx,group.group6alias"]
What I noticed is that all cartridges were started up although the cartridges are not going into active state (which is an issue in my test environment).
I tested a similar scenario with only cartridges defined in the application:
Deployed Application (see attached json (application_test_app5b.json):
"subscribables": ["c1alias51", "c2alias51", "c1xxx"
"dependencies": {
"startupOrders": [
"cartridge.c1alias51,cartridge.c2alias51",
"cartridge.c2alias51,cartridge.c1xxx"
],
and the system correctly brings up c1alias51 and then blocks all other cartridges (since they are not going active)
Thanks
Martin
From: Reka Thirunavukkarasu [mailto:reka@wso2.com]
Sent: Sunday, October 12, 2014 11:24 PM
To: Isuru Haththotuwa
Cc: dev; Martin Eppel (meppel); Udara Liyanage
Subject: Re: [Grouping][testing] Hierarchical Monitors with Composite Application
Hi
I have fixed them and committed it. Now that hierarchical monitors with the given definition is working fine..
Thanks,
Reka
On Mon, Oct 13, 2014 at 12:19 AM, Isuru Haththotuwa <is...@apache.org>> wrote:
On Mon, Oct 13, 2014 at 12:03 AM, Reka Thirunavukkarasu <re...@wso2.com>> wrote:
Thanks Isuru for pointing out..
Since i got to restarted while i was testing, i didn't face this issue. When i tried with the fresh setup, i faced the same issue..I did a fix for this. Will test it and update on it..
Great! Thanks Reka.
Thanks,
Reka
On Sun, Oct 12, 2014 at 11:55 PM, Isuru Haththotuwa <is...@apache.org>> wrote:
My Application is something similar to below:
[Inline image 1]
Both the cluster php1, php2 are notifying the parent as they are Activated. Also the group1 is also notifying the parent as its Activated. However, seems the group2 is not notifying the parent of its activation. Looking in to this further.
On Sun, Oct 12, 2014 at 5:55 PM, Isuru Haththotuwa <is...@apache.org>> wrote:
Hi Reka,
Great news!!
I tried with a similar Application, however there were no instance spawned for the top level Cartridge. But, both the Groups were successfully activated. Might be an issue with the definitions I used, have attached there here. Will check on this more.
On Sun, Oct 12, 2014 at 11:09 AM, Reka Thirunavukkarasu <re...@wso2.com>> wrote:
Hi all,
I have tested the hierarchical monitors with the attached sample application which has group2 and tomcat cartridge as in top level. group2 further refers to tomcat and group1. group1 further refers to php. Their startup order has also defined in the definitions as below mentioned:
For Eg:
app (group2, tomcat) implies that group2 should be started before tomcat.
The application structure is like:
--------------- app (group2, tomcat)----------------
| |
--------group2 (group1, tomcat)------- tomcat
| |
tomcat group1
|
php
For the above composite application structure, Application successfully became active after its children activated according to the start up order definied.
Please find the samples as attached. If you encounter any issue while testing, can you update the thread?
Thanks,
Reka
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile:
+94776442007
--
<tel:%2B94776442007>
Thanks and Regards,
Isuru H.
<tel:%2B94776442007>
+94 716 358 048
--
<tel:%2B94776442007>
Thanks and Regards,
Isuru H.
<tel:%2B94776442007>
+94 716 358 048<tel:%2B94776442007>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
--
<tel:%2B94776442007>
Thanks and Regards,
Isuru H.
<tel:%2B94776442007>
+94 716 358 048<tel:%2B94776442007>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
Re: [Grouping][testing] How to model nested dependencies ?
Posted by Isuru Haththotuwa <is...@apache.org>.
Hi Martin,
On Thu, Oct 16, 2014 at 4:10 AM, Martin Eppel (meppel) <me...@cisco.com>
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 to hear this!
>
>
> 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,
>
+1. There are several similar validations that we should do to improve the
Application Parser.
>
>
> Thanks
>
>
>
> Martin
>
>
>
>
>
>
>
> *From:* Reka Thirunavukkarasu [mailto:reka@wso2.com]
> *Sent:* Wednesday, October 15, 2014 2:04 AM
>
> *To:* Martin Eppel (meppel)
> *Cc:* dev@stratos.apache.org; 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) <me...@cisco.com>
> 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:* dev@stratos.apache.org; 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:reka@wso2.com <re...@wso2.com>]
> *Sent:* Monday, October 13, 2014 10:56 PM
> *To:* Martin Eppel (meppel)
> *Cc:* dev@stratos.apache.org; 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
>
> --
> <%2B94776442007>
> Thanks and Regards,
>
> Isuru H.
> <%2B94776442007>
> +94 716 358 048 <%2B94776442007>* <http://wso2.com/>*
>
>
> * <http://wso2.com/>*
>
>
>
Re: [Grouping][testing] How to model nested dependencies ?
Posted by Reka Thirunavukkarasu <re...@wso2.com>.
Hi
On Thu, Oct 16, 2014 at 4:10 AM, Martin Eppel (meppel) <me...@cisco.com>
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:reka@wso2.com]
> *Sent:* Wednesday, October 15, 2014 2:04 AM
>
> *To:* Martin Eppel (meppel)
> *Cc:* dev@stratos.apache.org; 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) <me...@cisco.com>
> 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:* dev@stratos.apache.org; 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:reka@wso2.com <re...@wso2.com>]
> *Sent:* Monday, October 13, 2014 10:56 PM
> *To:* Martin Eppel (meppel)
> *Cc:* dev@stratos.apache.org; 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
RE: [Grouping][testing] How to model nested dependencies ?
Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
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:reka@wso2.com]
Sent: Wednesday, October 15, 2014 2:04 AM
To: Martin Eppel (meppel)
Cc: dev@stratos.apache.org; 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) <me...@cisco.com>> 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: dev@stratos.apache.org<ma...@stratos.apache.org>; 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:reka@wso2.com]
Sent: Monday, October 13, 2014 10:56 PM
To: Martin Eppel (meppel)
Cc: dev@stratos.apache.org<ma...@stratos.apache.org>; 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
Re: [Grouping][testing] How to model nested dependencies ?
Posted by Reka Thirunavukkarasu <re...@wso2.com>.
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) <me...@cisco.com>
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:* dev@stratos.apache.org; 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:reka@wso2.com <re...@wso2.com>]
> *Sent:* Monday, October 13, 2014 10:56 PM
> *To:* Martin Eppel (meppel)
> *Cc:* dev@stratos.apache.org; 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
RE: [Grouping][testing] How to model nested dependencies ?
Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
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: dev@stratos.apache.org; 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:reka@wso2.com]
Sent: Monday, October 13, 2014 10:56 PM
To: Martin Eppel (meppel)
Cc: dev@stratos.apache.org<ma...@stratos.apache.org>; 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
RE: [Grouping][testing] How to model nested dependencies ?
Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
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:reka@wso2.com]
Sent: Monday, October 13, 2014 10:56 PM
To: Martin Eppel (meppel)
Cc: dev@stratos.apache.org; 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
Re: [Grouping][testing] How to model nested dependencies ?
Posted by Reka Thirunavukkarasu <re...@wso2.com>.
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