Hi Reka, I have a small concern on using the term "kill" in this scenario, I think it would be much more elegant if we call it something like "terminate". WDYT?
Thanks On Mon, Oct 6, 2014 at 11:44 AM, Reka Thirunavukkarasu <r...@wso2.com> wrote: > Hi all, > > I have implemented the dependency tree as mentioned in my mail earlier. It > will return the immediate children for the start able dependencies. > > FYI: a composite application has postgresGroup, php, mysqlGroup, app > server and esb as it's immediate children and their start up order is as > mentioned in the mail earlier. > > "startupOrders": [ > “postgresGroup, php", > "sqlGroup, tomcat", > "tomcat, apimanager", > "tomcat, esb” > ] > > So, if we look at the kill behaviour of this composite Application, it > will be like below: > > *kill-none* : none of them will be returned > > *kill-all*: all the elements in that dependency tree will be returned > For eg: if something happened to postgresGroup, then all the children > of dependency tree would be returned as php, mysqlGroup, app server and esb > will be get killed. > > *kill-dependent*: all the children of that particular node in the > dependency tree will be returned. > For eg: If something happened to mysqlGroup, then subsequently tomcat, > app server and esb would be get killed. > > Question: in case when we get more than one dependencies to be killed, can > we kill all of them in parallel or do we have to wait until it's dependent > cluster/group got killed? > > Thanks, > Reka > > On Thu, Oct 2, 2014 at 5:58 PM, Reka Thirunavukkarasu <r...@wso2.com> > wrote: > >> Hi Martin, >> >> On Wed, Oct 1, 2014 at 11:03 PM, Martin Eppel (meppel) <mep...@cisco.com> >> wrote: >> >>> Hi Reka, >>> >>> >>> >>> Are you suggesting to replace the current startupOrder definition with >>> the one mentioned below ? >>> >>> >>> >>> "startupOrder" : [ >>> >>> { >>> >>> "start":"aa", >>> >>> "after":"bb" >>> >>> } >>> >>> ] >>> >>> >>> >>> Replaced with >>> >>> >>> >>> "startupOrders": [ >>> >>> "mypostgresGroup, myphp", >>> >>> "mysqlGroup, mytomcat", >>> >>> "mytomcat, myapimanager", >>> >>> "mytomcat, myesb" >>> >>> ] >>> >>> >>> >>> I have a couple of questions, >>> >>> >>> >>> 1. If we use the cartridge alias and the group alias in the group >>> / application dependency definition how will it work when we auto scale >>> groups ? My current understanding is that to get group scaling to work we >>> would need 2 parameters – group name (==group.name) and group instance >>> id (== group.alias), one static and one dynamic. So I would think we’ll >>> have to define the application dependencies and group dependencies based on >>> the name and not the alias, but, during run time we have to calculate the >>> dependencies based on the alias. >>> >>> I think is important to make the distinction between group type (or >>> name,) and group instance Id, without it we won’t be able to implement >>> group scaling, wdyt ? >>> >> Thanks for pointing this out..Yah..As you have mentioned, if we are to >> scale the groups by creating new groups, then we will be unable to use the >> groups alias in place of startuporders. But stratos is tightly coupled with >> subscription to cluster as one to one mapping and also, load balancer uses >> one to one mapping between cluster and hostname. So, if we are to bring up >> new clusters/groups, then things might get complicated in stratos. As i >> explained in the [part-1] discussion, we thought of achieving scale by >> group member and scale by group using constructing the deployment policy in >> a more advanced manner. I will start a separate thread on that. According >> to all of our opinion, we can decide on how to follow that up. >> >>> IMHO the startupOrders in composite application and group definitions >>> (json ) should look like >>> >>> "startupOrders": [ >>> “postgresGroup, php", >>> "sqlGroup, tomcat", >>> "tomcat, apimanager", >>> "tomcat, esb” >>> ] >>> >>> while the runtime representation of the logical relationship model for >>> each group or cartridge should use the corresponding aliases (or instance >>> Id) so the monitor will reference the aliases (or instance Ids) while the >>> json application / group definition will reference the group name (or type) >>> and cartridge type to define the dependencies, WDYT ? >>> >>> 2. If for example a cartridge has multiple dependencies we would >>> just add another line to the the startupOrders : >>> >>> e.g. postgresGroup depends on php and abc would be >>> represented by: >>> "startupOrders": [ >>> "postgresGroup, php", >>> "postgresGroup, “abc” >>> …. >>> ] >>> >>> >>> >>> >>> >>> Otherwise I think the proposal looks good, +1 >>> >> >> Thanks, >> Reka >> >>> >>> >>> Thanks >>> >>> >>> >>> Martin >>> >>> >>> >>> *From:* Reka Thirunavukkarasu [mailto:r...@wso2.com] >>> *Sent:* Wednesday, October 01, 2014 5:58 AM >>> *To:* dev >>> *Cc:* Lakmal Warusawithana; Isuru Haththotuwa; Martin Eppel (meppel); >>> Udara Liyanage >>> *Subject:* [Grouping][Part-2] Composite Application Dependency Tree >>> building based in Autoscaler >>> >>> >>> >>> Hi >>> >>> >>> >>> As you aware, in the composite application we can define the depencies >>> between groups/cartridges. Autoscaler's responsible is to parse this >>> dependencies and build up a logical relationship model in order to handle >>> the dependency information among the child nodes. As we have the >>> hierarchical monitors in autoscaler, i propose to have dependencies >>> information in each monitor that they aware of (the immediate child only). >>> In that monitor, we need to identify the group/cartridge which can be >>> started in parallel. So that a monitor can look at it's dependency and >>> control it's immediate children based on that. Once all the children are >>> active, it can pass the control to it's parent. For Eg: >>> >>> >>> >>> If we take the top level in Composite application which has mysqlGroup, >>> postgresGroup, php, tomcat, apimanager and esb. If they have an alias >>> saying my + cartridge/groupName then we can define the dependency >>> information as follows: >>> >>> - myPhp depends on myPostgresGroup (means postgresGroup >>> should be started before php) >>> >>> - myTomcat depends on myMysqlGroup >>> >>> - myApiManager depends on myTomcat >>> >>> - myEsb depends on myTomcat >>> >>> >>> >>> Like wise, groups will define their own dependency as well. >>> >>> >>> >>> In that way, we need to represent these dependency information as part >>> of Composite Application definition/GroupDefinition. In order to represent >>> this dependency information given above for Composite Application, i would >>> suggest to have the following in Composite Application definition. >>> >>> >>> >>> "startupOrders": [ >>> >>> "mypostgresGroup, myphp", >>> >>> "mysqlGroup, mytomcat", >>> >>> "mytomcat, myapimanager", >>> >>> "mytomcat, myesb" >>> >>> ] >>> >>> >>> >>> You can use the same format in GroupDefinition to define dependencies in >>> a group. >>> >>> >>> >>> As per the example, autoscaler will build a dependency tree for >>> ApplicationMonitor as below in order to identify the parallel and dependent >>> ones. So that Autoscaler will start up same level children monitors as in >>> parallel. >>> >>> >>> >>> >>> >>> >>> As above, ApplicationMonitor will start GroupMonitors of myPostgresGroup >>> and myMysqlGroup in parallel. Once postgres becomes active, >>> ApplicationMonitor will start ClusterMonitor for myPhp. Once >>> myPostgresGroup becomes active, ApplicationMonitor will start the immediate >>> child myTomcat. Once myTomcat becomes active, ApplicationMonitor will start >>> the myAppServer and myEsb in parallel. This will be applicable for >>> GroupMonitors as well. They can look at their own dependency tree and will >>> start their children. >>> >>> >>> >>> Please share your suggestions on the above model to handle the >>> Dependency information of Composite Application in autoscaler. >>> >>> >>> >>> >>> >>> 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 >> >> >> > > > -- > Reka Thirunavukkarasu > Senior Software Engineer, > WSO2, Inc.:http://wso2.com, > Mobile: +94776442007 > > > -- Imesh Gunaratne Technical Lead, WSO2 Committer & PMC Member, Apache Stratos