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
