stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vanson Lim <>
Subject Re: Group Level Deployment Policy and Cartridge Level Deployment Policy
Date Wed, 15 Apr 2015 02:34:47 GMT
On 4/9/15, 8:19 AM, Reka Thirunavukkarasu wrote:
> 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 below:
> {
>    "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?*
> Pattern-2
> 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 cases.
> Thanks,
> Reka
> ​


For the use cases I've seen I think it's valuable (essential) to be able to control the min/max
instances of a cartridge at the cartridge 
level as shown in deployment pattern 2.  When C1 and C2 are unlike cartridges, we need to
be able to individually control the min and max 
instances of each cartridge independently.  For example, if C1=web server and C2=cassandra
databases,  I can't imagine ever having the same 
number web servers as there are database backends.

I can also see value with pattern 1 for some uses cases where you want the instances of a
group to be on the same partition and achieve 
high availability by having multiple instances of groups spread across partitions.  We don't
currently plan to use pattern 1 for our uses 
cases but I also don't want to be too restrictive on the implementation such that it is inflexible
for others who may think of other uses 

A few points I find confusing:
1) When we have a group deployment policy, why doesn't the PartitionMin/Max value apply to
the individual cartridge instances instead of 
the instances of the group?

2) It seems to me that the cartridge deployment policy should override any group level definitions
of min/max instances.  Defining of 
partitionMin/Max at the group level and applying it to the number of cartridge instances instead
of group instances just seems wrong.

We seem to have the following requirements if we want to support both pattern 1 and 2.

R1) if we want control VM placement at the group policy level (pattern 1)

a) define deployment number of group instances at the policy with partitions.   Partition
min max at in the group policy defines the number 
of group instances per partition.
b) support only defining min/max instance per cartridge, not partition.

R2) if we want to control VM placement at the cartridge level (pattern 2)

a) group level deployment policy should only specify the min/max instances of the group, not
the partition the group runs in.
b) each cartridge needs a cartridge level deployment policy

R3) if we want to control the VM placement of a group instance and different number of cartridges
depending on partition (another variant 
of pattern 1, also covers R1 above)

a) define deployment number of group instances at the policy with partitions.   Partition
min max at in the group policy defines the number 
of group instances per partition.
b) define deployment policy at the cartridge level containing a partition definition for each
partition defined in the group.   When a 
group instance occupies a partitions P1, then only a cartridges P1 partition definitions applies.
   For example, if we have a group 
deployment policy containing a P1 and P2, and  a cartridge C1 has a deployment policy with
partition P2 and P3,   when the group is 
scheduled in P1, there will be zero instances of C1 because there is no corresponding partition
defined for that cartridge.

Supporting requirements R1, R2 and R3 boils down to the following 3 Features:

F1) deployment policy needs to support defining either a list of partitions or just a min/max
(meaning the min/max whichever partition this 
cartridge is deployed in)
F2) the min/max in a deploy policy should apply at the level at which it's defined.  If it's
a group policy then it should be instances of 
a group.  And if defined at a cartridge level applies to instances of that cartridge.
F3) if we want to support placement at the group level and enforce placement of cartridges
based on group placement, there has to be the 
same partitions defined at the cartridge level as at the group level.  If there is no like
partition defined then it implied that the 
cartridges has P1 defined with partitionMin/Max=0 (or is it better to imply 1 instead of 0)
for that partition.


> -- 
> Reka Thirunavukkarasu
> Senior Software Engineer,
> WSO2, Inc.:,
> Mobile: +94776442007 <tel:%2B94776442007>

View raw message