Hi Shaheedur, This is the same model we had from 4.0.0 and we did not change the concept in this release. Explanation as below,
There can be several partitions that a particular cartridge(service cluster) can span over. E.g. Say PHP cartridge have 3 partitions(P1 and P2). P1 has 3 as partition max and P1 has 6 as partition max. PHP has 2 as Cartridge min and 5 as Cartridge max. *With one-after-another algorithm between partitions,* *Min instances creation,* Both the minimum instances will be created in P1. *Scaling up,* First scaling up member will be created in P1 and the next members will be created in P2. It can only create 3 members in P1 and 2 members in P2 as it will reach it's max of 5 members. That's where the cartridge max is used. *With round-robin algorithm between partitions,* *Min instances creation,* One of the minimum instances will be created in P1 and the other in P2. *Scaling up,* Scaling up members will be created in round-robin manner in P1 and P2. On Fri, Mar 13, 2015 at 9:31 PM, Shaheedur Haque (shahhaqu) < shahh...@cisco.com> wrote: > After discussing a bit with Imesh, we identified 3 points that need > clarifying: > > > > · If there is to be a cartridgeMin attribute, it should at least > be optional and take its default value from the deployment policy minimum > value. > Do you mean the minimum value per partition? I cannot see such value. There is only maximum in partitions of deployment policy. > · If there is to be a cartridgeMin attribute, its behaviour needs > to be specified with respect to the deployment min and max. For example, > what happens if the cartridgeMin is greater than the deployment max? > This is a good question. Ideally, with current implementation, it will not create instances beyond partition Max. > · We need to find out what, if anything, the cartridgeMax is for. > IMO partition max are for limiting the instances in IaaS, for particular region, zone or so. But cartridge need it's own limit when it scales up, where reusable partitions may have less or more space. Therefore we need both. *Stratos will create instances until the lowest of those max values(Cartridge max and partition max).* Thanks. > > > > > > > *From:* Shaheedur Haque (shahhaqu) > *Sent:* 13 March 2015 08:22 > *To:* dev@stratos.apache.org > *Subject:* RE: [Discuss] Cartridge definition doesn't need > "maxInstanceLimit" property anymore > > > > Hi Reka, > > > > First, I strongly suggest we not use internal terms like “cluster”, since > they are not part of the user visible model, to explain user visible > behaviour. For example, my understanding of a cluster is almost certainly > not as good as you think it is J. Nevertheless… > > > > I think I understand: you are saying that when a group scales up, you will > initially spin up cartridgeMin instances, correct? If this is not correct, > please clarify. If it is correct, then: > > > > · I would have thought that the correct behaviour was to enforce > the minimum value specified in the deployment policy. > > · Even if there is a theoretical use case where a new group should > start with a different values that the one in the deployment policy, you > would need to clearly explain how cartridgeMin relates to both deployment > min **and** max when the values clash. I say we should rather keep it > simple and use the deployment policy values. > > · What is cartridgeMax used for? > > > > Thanks, Shaheed > > > > *From:* Reka Thirunavukkarasu [mailto:r...@wso2.com <r...@wso2.com>] > *Sent:* 13 March 2015 02:54 > *To:* dev > *Subject:* Re: [Discuss] Cartridge definition doesn't need > "maxInstanceLimit" property anymore > > > > Hi Shaheedur, > > Sorry for the confusion..Let me explain what cartridgeMin is and the > purpose of having it in the application. As you already aware, we have > the group instances/cluster instances concept with 4.1.0 in order to > support group scaling. For the cluster level, we will need a minimum count > for the members in order to maintain this minimum count all the time. Since > we have cluster instance concept, we will need a minimum members per > cluster instance level. So that whenever a new cluster instance is getting > created, we can satisfy the cluster instance by creating the cartridgeMin > number of members and can send the clusterInstanceActivated event. That's > why > cartridgeMin got introduced in the application. "cartridgeMin" means the > minimum number of members per cluster instance. > > When a cluster instance is getting created, let's say you have two as the > cartridgeMin. In that case in order to create those two members, we will > need to find out the partition. For that, we will get the associated policy > and find the suitable partition to spin those members one by one. If one of > the partition is full, our algorithm is capable of choosing the next > available partition. > > Please let me know, if it is unclear still.. > > Thanks, > > Reka > > > > On Thu, Mar 12, 2015 at 11:31 AM, Shaheedur Haque (shahhaqu) < > shahh...@cisco.com> wrote: > > I’m now thoroughly confused as to what is going and staying. I **think** > the latest part of this thread says we need to keep cartridgeMin and > cartridgeMax. Why do we need cartridgeMin and cartridgeMax at this point in > the system? > > > > *From:* Reka Thirunavukkarasu [mailto:r...@wso2.com] > *Sent:* 12 March 2015 17:09 > *To:* dev > *Subject:* Re: [Discuss] Cartridge definition doesn't need > "maxInstanceLimit" property anymore > > > > Hi Raj, > > > > On Thu, Mar 12, 2015 at 10:01 AM, Rajkumar Rajaratnam <rajkum...@wso2.com> > wrote: > > > > > > On Thu, Mar 12, 2015 at 10:24 PM, Reka Thirunavukkarasu <r...@wso2.com> > wrote: > > Hi Lahiru/Raj, > > I think that we have introduced this *cartridgeMin/cartridgeMax *when > introducing the deployment policy for cartridge and groups as global > deployment policy. Since we have the same concept now, i would like to > review the implementation and confirm whether it is required or not. Can > you please hold until that? I will quickly confirm on this.. > > > > Hi Reka, I am not sure whether I understood you wrong. Yes we need > cartridgeMin and cartridgeMax, which are defined in application json. But > we don't need *maxInstanceLimit* property, which used to define in > cartridge json in 4.0.0. I guess we have already removed references to this > property from code base, but not from sample artifacts. > > > > Thanks for the details.. We no longer using *maxInstanceLimit. *+1 to > remove it..I was bit confused when i read the mail body as i thought that > you are going to remove cartidgeMin/cartridgeMax. Now it is clear.. > > Thanks, > > Reka > > > > > > Thanks, > > Reka > > > > On Thu, Mar 12, 2015 at 9:40 AM, Lahiru Sandaruwan <lahi...@wso2.com> > wrote: > > Noticed today. It was misleading as we have this left in samples. I will > clean this up. > > > > Thanks. > > > > On Thu, Mar 12, 2015 at 10:04 PM, Rajkumar Rajaratnam <rajkum...@wso2.com> > wrote: > > Hi Devs, > > We are defining cartridge min max count in application definition. > > { > "applicationId": "single-cartridge-app", > "alias": "single-cartridge-app", > "multiTenant": false, > "components": { > "cartridges": [ > { > "type": "php", > > *"cartridgeMin": 1, "cartridgeMax": 10,* > "subscribableInfo": { > "alias": "my-php", > "autoscalingPolicy": "autoscaling-policy-1", > "deploymentPolicy": "deployment-policy-1", > "artifactRepository": { > "privateRepo": false, > "repoUrl": " > https://github.com/imesh/stratos-php-applications.git";, > "repoUsername": "", > "repoPassword": "" > } > } > } > ] > } > } > > In 4.0.0, we used to define these in cartridge definition, in IaaS > provider section. We have now removed it from cartridge bean classes. > However I can see that samples still have this attribute. I will remove it. > > Thanks. > > > -- > > Rajkumar Rajaratnam > > Committer & PMC Member, Apache Stratos > > Software Engineer, WSO2 > > Mobile : +94777568639 > > Blog : rajkumarr.com > > > > > > -- > > -- > Lahiru Sandaruwan > > Committer and PMC member, Apache Stratos, > Senior Software Engineer, > WSO2 Inc., http://wso2.com > > lean.enterprise.middleware > > phone: +94773325954 > email: lahi...@wso2.com blog: http://lahiruwrites.blogspot.com/ > linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146 > > > > > > -- > > Reka Thirunavukkarasu > Senior Software Engineer, > WSO2, Inc.:http://wso2.com, > > Mobile: +94776442007 > > > > > > > -- > > Rajkumar Rajaratnam > > Committer & PMC Member, Apache Stratos > > Software Engineer, WSO2 > > Mobile : +94777568639 > > Blog : rajkumarr.com > > > > > -- > > Reka Thirunavukkarasu > Senior Software Engineer, > WSO2, Inc.:http://wso2.com, > > Mobile: +94776442007 > > > > > > > -- > > Reka Thirunavukkarasu > Senior Software Engineer, > WSO2, Inc.:http://wso2.com, > > Mobile: +94776442007 > > > -- -- Lahiru Sandaruwan Committer and PMC member, Apache Stratos, Senior Software Engineer, WSO2 Inc., http://wso2.com lean.enterprise.middleware phone: +94773325954 email: lahi...@wso2.com blog: http://lahiruwrites.blogspot.com/ linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
