Before going further we all need to come to same picture of the functional requirements and required API changes ( compared to 4.0.0 ) for the implementation.
Sometimes we may need to have webex call to understand clear picture of the problem On Thursday, April 9, 2015, Reka Thirunavukkarasu <r...@wso2.com> 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 > https://issues.apache.org/jira/browse/STRATOS-1297 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 > > > > > > -- > Reka Thirunavukkarasu > Senior Software Engineer, > WSO2, Inc.:http://wso2.com, > Mobile: +94776442007 > > > -- Sent from Gmail Mobile
