Please don't specify max/min in the group definition. It should be
specified in the application as in group level/cartridge level
appropriately. Please see the correct group definition as inline:
{
"name": "group6",
"groups": [
{
"name": "group7",
"cartridges": [
"tomcat1"
]
}
],
"cartridges": [
"tomcat2"
],
"dependencies": {
"startupOrders": [
"group.group7,cartridge.tomcat2"
],
"terminationBehaviour": "terminate-all"
}
}
On Sat, Dec 6, 2014 at 1:12 AM, Reka Thirunavukkarasu <[email protected]> wrote:
> Hi Martin,
>
> I have attached here with the sample application definition and the
> deployment policy. Could you please have a look at those samples?
>
> Yah. We no longer support the partition min instead we define members min
> per cluster instance and minimum required group instances in the group of
> the application. But relevant partitions in the deployment policy will have
> the partition max. So that at some point partition will become max out.
>
> We define max in group level or cartridge as well. That will get used only
> when we don't have a policy associated in group level/cartridge level
> directly.
>
> We are still testing and fixing issues. So, when you deploy this, you may
> face some issues..
>
> Thanks,
> Reka
>
> On Sat, Dec 6, 2014 at 12:51 AM, Martin Eppel (meppel) <[email protected]>
> wrote:
>
>> In 4.0 we had a min parameter in the partition definition (see example
>> below, highlighted), is it still supported in the new format ?
>>
>>
>>
>> In 4.0:
>>
>> "id": "static-1-Core",
>>
>> "partitionGroup": {
>>
>> "id": "N1",
>>
>> "partition": [
>>
>> {
>>
>> "id": "RegionOne-Core",
>>
>> "partitionMax": "1",
>>
>> "*partitionMin": "1"*
>>
>> }
>>
>> ],
>>
>> "partitionAlgo": "one-after-another"
>>
>> }
>>
>> }
>>
>>
>>
>> In 4.1
>>
>> + networkPartition[1..n]
>>
>> + id
>>
>> + partition[1..n]
>>
>> + id
>>
>> + max
>>
>> *? + min ?*
>>
>>
>>
>>
>>
>> *From:* Martin Eppel (meppel)
>> *Sent:* Sunday, November 30, 2014 4:32 PM
>> *To:* [email protected]
>> *Subject:* RE: Global Deployment Policy for the Application
>>
>>
>>
>> Hi Reka,
>>
>>
>>
>> We also need an extra parameter for group deployment policies which
>> defines if “children” (or group member) should be collocated (or not),
>> please see in the grouping specification “these Children must be
>> physically next to each other”, not sure how this will expressed in the
>> application deployment policy. I would suggest a boolean expression as
>> shown below, WDYT ?
>>
>>
>>
>> …
>>
>> + childPolicies[1..n]
>>
>> + childId (Group alias or cartridge alias)
>>
>>
>>
>> *+ collocate* //
>>
>>
>>
>> + networkPartition[1..n]
>>
>> + id
>>
>> + partition[1..n]
>>
>> + id
>>
>> + max
>>
>>
>>
>>
>>
>> Thanks
>>
>>
>>
>> Martin
>>
>>
>>
>> *From:* Reka Thirunavukkarasu [mailto:[email protected] <[email protected]>]
>> *Sent:* Saturday, November 29, 2014 8:53 PM
>> *To:* dev
>> *Subject:* Global Deployment Policy for the Application
>>
>>
>>
>> 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
>>
>>
>>
>
>
>
> --
> Reka Thirunavukkarasu
> Senior Software Engineer,
> WSO2, Inc.:http://wso2.com,
> Mobile: +94776442007
>
>
>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
