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
?
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
Martin
From: Reka Thirunavukkarasu [mailto:[email protected]]
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.
[cid:[email protected]]
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<tel:%2B94776442007>
