Hi Reka,
So if I try to model the following (real use case) with 2 levels of nested
groups and the startup dependencies tomcat3 -> group8 -> tomcat1 ->group7 –
tomcat2 -> group6
it will be defined as follows (see inline definition for 2nd level of nesting
-> group8 in bold) :
I assume that similarly I have to define the alias and subscriptions info
inline in the application definition.
{
"name": "group6",
"groups": [
{
"name": "group7",
"groups": [
{
"name": "group8",
"cartridges": [
"tomcat3"
]
}
],
"cartridges": [
"tomcat1"
],
"dependencies": {
"startupOrders": [
"group.group8,cartridge.tomcat1"
],
"terminationBehaviour": "terminate-all"
}
}
],
"cartridges": [
"tomcat2"
],
"dependencies": {
"startupOrders": [
"group.group7,cartridge.tomcat2"
],
"terminationBehaviour": "terminate-all"
}
}
Th
From: Reka Thirunavukkarasu [mailto:[email protected]]
Sent: Monday, December 08, 2014 12:22 PM
To: dev
Subject: Re: Global Deployment Policy for the Application
Hi Martin,
On Tue, Dec 9, 2014 at 12:46 AM, Martin Eppel (meppel)
<[email protected]<mailto:[email protected]>> wrote:
Resending it in case you missed it
Thanks
Martin
From: Martin Eppel (meppel)
Sent: Friday, December 05, 2014 1:42 PM
To: [email protected]<mailto:[email protected]>
Subject: RE: Global Deployment Policy for the Application
Hi Reka,
I was looking at the attached samples and had a few questions:
Did we change the group format ? In the sample you sent out there is a group6
and group7 defined. What is the meaning of the cartridges (“tomcat1”) section
in the groups section for “group7”, see below ? Don’t we have to define
“group7” separately (the zip file with the sample did not contain a
group7.json)?
Yah..We are defining the nested group as inline in order to increase the
readability. If we are to have a nested group, then we should deploy it as a
single group by having all the necessary nested groups's definition in it.
Also, in the application definition we seem to duplicate information as in the
group6c.json (e.g. "groupMinInstances":1) ? How would the
application_definition.json and respective group.json files look like if group7
also has a nested group (we do have a use case for this) ?
Please refer the attached modified sample..It has the correct syntax. We will
be specifying the min/max in the application definition only as it engages with
the deployment. However, if you are having a nested group, then with the
current implementation, you will have to put that nested group in the
application definition and provide alias and other info by recursively going
through the nested group.
Thanks,
Reka
Thanks
Martin
{
"name": "group6",
"groupMinInstances":1,
"groupMaxInstances":1,
"groups": [
{
"name": "group7",
"groupMinInstances":1,
"groupMaxInstances":1,
"cartridges": [
"tomcat1"
]
}
],
"cartridges": [
"tomcat2"
],
"dependencies": {
"startupOrders": [
"group.group7,cartridge.tomcat2"
],
"terminationBehaviour": "terminate-all"
}
}
From: Martin Eppel (meppel)
Sent: Friday, December 05, 2014 11:49 AM
To: [email protected]<mailto:[email protected]>
Subject: RE: Global Deployment Policy for the Application
Thanks Reka,
From: Reka Thirunavukkarasu [mailto:[email protected]]
Sent: Friday, December 05, 2014 11:43 AM
To: dev
Subject: Re: Global Deployment Policy for the Application
Hi Martin,
I have attached here with the sample application definition and the deployment
policy. Could you please have a look at those samples?
Yah. We no longer support the partition min instead we define members min per
cluster instance and minimum required group instances in the group of the
application. But relevant partitions in the deployment policy will have the
partition max. So that at some point partition will become max out.
We define max in group level or cartridge as well. That will get used only when
we don't have a policy associated in group level/cartridge level directly.
We are still testing and fixing issues. So, when you deploy this, you may face
some issues..
Thanks,
Reka
On Sat, Dec 6, 2014 at 12:51 AM, Martin Eppel (meppel)
<[email protected]<mailto:[email protected]>> wrote:
In 4.0 we had a min parameter in the partition definition (see example below,
highlighted), is it still supported in the new format ?
In 4.0:
"id": "static-1-Core",
"partitionGroup": {
"id": "N1",
"partition": [
{
"id": "RegionOne-Core",
"partitionMax": "1",
"partitionMin": "1"
}
],
"partitionAlgo": "one-after-another"
}
}
In 4.1
+ networkPartition[1..n]
+ id
+ partition[1..n]
+ id
+ max
? + min ?
From: Martin Eppel (meppel)
Sent: Sunday, November 30, 2014 4:32 PM
To: [email protected]<mailto:[email protected]>
Subject: RE: Global Deployment Policy for the Application
Hi Reka,
We also need an extra parameter for group deployment policies which defines if
“children” (or group member) should be collocated (or not), please see in the
grouping specification “these Children must be physically next to each other”,
not sure how this will expressed in the application deployment policy. I would
suggest a boolean expression as shown below, WDYT ?
…
+ childPolicies[1..n]
+ childId (Group alias or cartridge alias)
+ collocate //
+ networkPartition[1..n]
+ id
+ partition[1..n]
+ id
+ max
Thanks
Martin
From: Reka Thirunavukkarasu [mailto:[email protected]]
Sent: Saturday, November 29, 2014 8:53 PM
To: dev
Subject: Global Deployment Policy for the Application
Hi all,
In grouping, as we are supporting deployment Policy in the group level or in
the cluster level, it would be easy if we have a single place to define all the
deployment policy of children. The advantages of defining global deployment
policy as below:
- Same application can be deployed in HA or in burst manner using different
deployment Policy.
* will be starting actual VMs after deploying the deployment Policy
rather than starting it, once the application got deployed.
* deployment Policy will be coupled with an application always.
- No need to define multiple deployment policy per cluster level or group level
- Validation can also happen in the single place
* Each children's policy can be validated against the applicationPolicy
whether relevant partition/Network partition is already defined or not
* Each leave cluster should have a deployment policy either inherit from
one of the parent group or define it by its own.
- Partition can also be defined in the Deployment Policy itself
Please find the proposed format for the deployment Policy for application as
following:
+ id
+ applicationPolicy[1..1]
+ appId
+ networkPartition[1..n]
+ id
+ activeByDefault
+ partition[1..n]
+ id
+ provider
+ properties[1..n]
+ childPolicies[1..n]
+ childId (Group alias or cartridge alias)
+ networkPartition[1..n]
+ id
+ partition[1..n]
+ id
+ max
Please find the definition of new elements in the Deployment Policy as below:
applicationPolicy : will have definition of all the network partition and
partition which will be used throughout the application.
activeByDefault : If true means, that network partition will be used by
default. If false, means it can be used when all the resources are exhausted(in
bursting)
childPolicies : Each child policy will refer the network partition and relevant
partition from applicationPolicy to define their own deployment pattern. Please
note that, if you define a childPolicy by referring to group, then underlying
clusters/group will inherit the same policy.
max: Maximum no of instances that can be handled by a partition.
For group: max group instances can be in a partition
For Cluster: max members that can be kept for a cluster instance in a
partition.
FYI: A sample Policy is attached here with.
Please share your suggestions on this...
Thanks,
Reka
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007<tel:%2B94776442007>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007<tel:%2B94776442007>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
