stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reka Thirunavukkarasu <>
Subject Group Level Deployment Policy and Cartridge Level Deployment Policy
Date Thu, 09 Apr 2015 12:19:45 GMT
Hi All,

We have discussed about the handling deployment policy in group level and
caridge level in multiple other mails. I have started to look into and thought of
discussing my concerns before implementing/fixing the flow. Sorry for the
long mail as i couldn't explain the concept in a short mail.

The current Design on Deployment Policy

We can have deployment policy in all the leaf level as in cartridge level.
Since defining cartrdigeMin and cartiridgeMax along with defining
partitionMax in the deployment policy complicates the user, we are going to
go with defining partitionMin and partitionMax in the deployment policy for
the cartridge as below.

   "id": "deployment-policy-1",
   "networkPartitions": [
         "id": "network-partition-1",
         "partitionAlgo": "one-after-another",
         "partitions": [
               "id": "partition-1",
               "partitionMin" : 2,
               "partitionMax": 20

When we have the above deployment policy in each cartridge level of an
application, each cluster instance can refer to that and adhere to the
min/max members as defined in the policy.

Since we have Group scaling/high availability for the groups by supporting
group instances concept, when you deploy an application, an application
instance will get created. Then based on the definition of application,
Group instance for a group and cluster instance for a cartridge will get
created where group instance. When Group scaling is enabled or there is a
chance to create multiple group instances, then we can define the group
instance deployment pattern as below:

Eg: G1 has C1 and C2  where one GroupInstnace of G1 has two C1 members and
two C2 members.

​ *Pattern-1*

This is the high availability pattern for the group where one group
instance will be reside in one partition. In order to deploy in pattern-1,
we will need a deployment policy in the Group level. If we define a
Deployment Policy in the group level, then underlying cartridges should use
the algorithm and the partition selected by the parent in order to create
new members. Then only the members of the same group instance can be
deployed into the same partition. The sample Group level policy would be as

   "id": "deployment-policy-G1",
   "networkPartitions": [
         "id": "network-partition-1",
         "partitionAlgo": "round-robin",
         "partitions": [
               "id": "P1",
               "partitionMin" : 1,
               "partitionMax": 2
               "id": "P2",
               "partitionMin" : 1,
               "partitionMax": 2

With this policy, two group instances(G11 and G12) gets created in P1 and
P2 respectively. Since we don't define another deployment policy in
cartridge level, cartridges need to use the same min/max defined in the
group level deployment policy. This will be a limitation as cartridges are
unable to enforce their own min/max.* How can the underlying cartridges
created their member without a min/max in the cartridge level?*  *Would
that make sense to read the Group level deployment policy for the
underlying cartridges as well?*


In order to deploy the group instances across partitions, we don't need a
deployment policy in the group level. The partitions will be decided by the
children. But we will need to specify  GroupMinInstances and
GroupMaxInstances in the group level. Then only we can control the number
group instances to be created. Since we are moving from defining
GroupMinInstances and GroupMaxInstances in the application, how can we
handle this as we don't need a policy for this case? *Can we keep the
GroupMinInstances and GroupMaxInstances in the application?*

Please provide your  feedback on migrating from cartridgeMin/cartridgeMax
to deployment policy's partitionMin/partitionMax as above two patterns need
to be fixed properly. If anyone aware of more real use cases, please let me
know. It would help improving this model further to fit with more real use



Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:,
Mobile: +94776442007

View raw message