On Sun, Nov 30, 2014 at 11:28 PM, Isuru Haththotuwa <[email protected]> wrote:
> > > On Sun, Nov 30, 2014 at 10:54 PM, Lahiru Sandaruwan <[email protected]> > wrote: > >> Looks good Reka, >> >> We might need to get the minimum count of instances of a particular >> cluster. >> > +1, this should be min per cluster instance AFAIU. > Correct. > >> We can get it per cluster which will be effective for all the network >> partitions or per network partition. >> > since an application instance is spanning across a network partition, this > should be per single network partition IMO. > I also feel the same. Someone might need different mins for different network partitions. Thanks. > >> If it is per cluster, >> >> + 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) >> *+ min* >> + networkPartition[1..n] >> + id >> + partition[1..n] >> + id >> + max >> >> If it is per network partition, >> >> + 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 >> *+ min* >> + partition[1..n] >> + id >> + max >> @devs, >> >> Which way do you guys think better? >> >> Thanks. >> >> On Sun, Nov 30, 2014 at 10:23 AM, Reka Thirunavukkarasu <[email protected]> >> wrote: >> >>> 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 >>> >>> >>> >> >> >> -- >> -- >> Lahiru Sandaruwan >> Committer and PMC member, Apache Stratos, >> Senior Software Engineer, >> WSO2 Inc., http://wso2.com >> lean.enterprise.middleware >> >> email: [email protected] blog: http://lahiruwrites.blogspot.com/ >> linked-in: >> http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146 >> >> -- >> <http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146> >> <http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146> >> Thanks and Regards, >> >> Isuru H. >> <http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146> >> +94 716 358 048 <http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146>* >> <http://wso2.com/>* >> >> >> * <http://wso2.com/>* >> >> >> -- -- Lahiru Sandaruwan Committer and PMC member, Apache Stratos, Senior Software Engineer, WSO2 Inc., http://wso2.com lean.enterprise.middleware email: [email protected] blog: http://lahiruwrites.blogspot.com/ linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
