You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by "Martin Eppel (meppel)" <me...@cisco.com> on 2014/12/01 01:31:47 UTC

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:reka@wso2.com]
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<tel:%2B94776442007>


Re: Global Deployment Policy for the Application

Posted by Reka Thirunavukkarasu <re...@wso2.com>.
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 <re...@wso2.com> 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) <me...@cisco.com>
> 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:* dev@stratos.apache.org
>> *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:reka@wso2.com <re...@wso2.com>]
>> *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

Re: Global Deployment Policy for the Application

Posted by Manula Chathurika Thantriwatte <ma...@wso2.com>.
Hi Martin,

Yes, you are correct. "applicationId":"test_app_os4" have match with the
applicationId which we were using.

Thanks !

On Sat, Dec 6, 2014 at 3:26 AM, Martin Eppel (meppel) <me...@cisco.com>
wrote:

>  One more question, in the deployment_policy.json there is a filed
> "applicationId": "test_app_os4", – does it have to match up with the
> applicationId of the application where it is used or is it arbitrarily ?
> Also, where is the deployment policy referenced – I would have expect it in
> the subscribableInfo but I don’t see a reference ?
>
>
>
>
>
> "subscribableInfo": {
>
>                             "alias": "group6tom",
>
>                             "autoscalingPolicy": "autoscale_policy_1"
>
>                         }
>
>
>
>
>
> *From:* Martin Eppel (meppel)
> *Sent:* Friday, December 05, 2014 1:42 PM
>
> *To:* dev@stratos.apache.org
> *Subject:* RE: Global Deployment Policy for the Application
>
>
>
> Hi Reka,
>
>
>
> I was looking at the attached samples and had a few questions:
>
>
>
> Did we change the group format ? In the sample you sent out there is a
> group6 and group7 defined. What is the meaning of the cartridges
> (“tomcat1”) section in the groups section for “group7”, see below ? Don’t
> we have to define “group7” separately (the zip file with the sample did not
> contain a group7.json)?
>
>
>
> Also, in the application definition we seem to duplicate  information as
> in the group6c.json (e.g. "groupMinInstances":1) ? How would the
> application_definition.json and respective group.json files look like if
> group7 also has a nested group (we do have a use case for this) ?
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
>
>
>
>
>
>
> {
>
>     "name": "group6",
>
>     "groupMinInstances":1,
>
>     "groupMaxInstances":1,
>
>     "groups": [
>
>         {
>
>             "name": "group7",
>
>             "groupMinInstances":1,
>
>             "groupMaxInstances":1,
>
>             "cartridges": [
>
>                 "tomcat1"
>
>             ]
>
>         }
>
>
>
>     ],
>
>     "cartridges": [
>
>         "tomcat2"
>
>     ],
>
>     "dependencies": {
>
>         "startupOrders": [
>
>             "group.group7,cartridge.tomcat2"
>
>         ],
>
>         "terminationBehaviour": "terminate-all"
>
>     }
>
> }
>
>
>
> *From:* Martin Eppel (meppel)
> *Sent:* Friday, December 05, 2014 11:49 AM
> *To:* dev@stratos.apache.org
> *Subject:* RE: Global Deployment Policy for the Application
>
>
>
> Thanks Reka,
>
>
>
>
>
>
>
> *From:* Reka Thirunavukkarasu [mailto:reka@wso2.com <re...@wso2.com>]
> *Sent:* Friday, December 05, 2014 11:43 AM
> *To:* dev
> *Subject:* Re: Global Deployment Policy for the Application
>
>
>
> 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) <me...@cisco.com>
> 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:* dev@stratos.apache.org
> *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:reka@wso2.com <re...@wso2.com>]
> *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
>
>
>



-- 
Regards,
Manula Chathurika Thantriwatte
Software Engineer
WSO2 Inc. : http://wso2.com
lean . enterprise . middleware

email : manulac@wso2.com / manula@apache.org
phone : +94 772492511
blog : http://manulachathurika.blogspot.com/

RE: Global Deployment Policy for the Application

Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
One more question, in the deployment_policy.json there is a filed "applicationId": "test_app_os4", – does it have to match up with the applicationId of the application where it is used or is it arbitrarily ? Also, where is the deployment policy referenced – I would have expect it in the subscribableInfo but I don’t see a reference ?


"subscribableInfo": {
                            "alias": "group6tom",
                            "autoscalingPolicy": "autoscale_policy_1"
                        }


From: Martin Eppel (meppel)
Sent: Friday, December 05, 2014 1:42 PM
To: dev@stratos.apache.org
Subject: RE: Global Deployment Policy for the Application

Hi Reka,

I was looking at the attached samples and had a few questions:

Did we change the group format ? In the sample you sent out there is a group6 and group7 defined. What is the meaning of the cartridges (“tomcat1”) section in the groups section for “group7”, see below ? Don’t we have to define “group7” separately (the zip file with the sample did not contain a group7.json)?

Also, in the application definition we seem to duplicate  information as in the group6c.json (e.g. "groupMinInstances":1) ? How would the application_definition.json and respective group.json files look like if group7 also has a nested group (we do have a use case for this) ?

Thanks

Martin




{
    "name": "group6",
    "groupMinInstances":1,
    "groupMaxInstances":1,
    "groups": [
        {
            "name": "group7",
            "groupMinInstances":1,
            "groupMaxInstances":1,
            "cartridges": [
                "tomcat1"
            ]
        }

    ],
    "cartridges": [
        "tomcat2"
    ],
    "dependencies": {
        "startupOrders": [
            "group.group7,cartridge.tomcat2"
        ],
        "terminationBehaviour": "terminate-all"
    }
}

From: Martin Eppel (meppel)
Sent: Friday, December 05, 2014 11:49 AM
To: dev@stratos.apache.org<ma...@stratos.apache.org>
Subject: RE: Global Deployment Policy for the Application

Thanks Reka,



From: Reka Thirunavukkarasu [mailto:reka@wso2.com]
Sent: Friday, December 05, 2014 11:43 AM
To: dev
Subject: Re: Global Deployment Policy for the Application

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) <me...@cisco.com>> 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: dev@stratos.apache.org<ma...@stratos.apache.org>
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:reka@wso2.com]
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<tel:%2B94776442007>




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


Re: Global Deployment Policy for the Application

Posted by Reka Thirunavukkarasu <re...@wso2.com>.
Hi Martin.

On Tue, Dec 9, 2014 at 10:18 AM, Martin Eppel (meppel) <me...@cisco.com>
wrote:

>  Hi Reka,
>
>
>
> So if I try to model the following (real use case) with 2 levels of nested
> groups and the startup dependencies tomcat3 -> group8 -> tomcat1 ->group7 –
> tomcat2 -> group6
>
>
>
> it will be defined as follows (see inline definition for 2nd level of
> nesting -> group8 in bold) :
>
>
>
> I assume that similarly I have to define the alias and subscriptions info
> inline in the application definition.
>
>
>
> {
>
>     "name": "group6",
>
>     "groups": [
>
>         {
>
>             "name": "group7",
>
> "groups": [
>
>                *       {*
>
> *                        "name": "group8",*
>
> *                         "cartridges": [*
>
> *                         "tomcat3"*
>
> *                                    ]*
>
> *                  }*
>
>             ],
>
>             "cartridges": [
>
>                 "tomcat1"
>
>             ],
>
>
>
>            *"dependencies": {*
>
> *              "startupOrders": [*
>
> *               "group.group8,cartridge.tomcat1"*
>
> *               ],*
>
> *              "terminationBehaviour": "terminate-all"*
>
> *         }*
>
>
>
>         }
>
>
>
>     ],
>
>     "cartridges": [
>
>         "tomcat2"
>
>     ],
>
>     "dependencies": {
>
>         "startupOrders": [
>
>             "group.group7,cartridge.tomcat2"
>
>         ],
>
>         "terminationBehaviour": "terminate-all"
>
>     }
>
> }
>
>
>
Yah..This is correct definition for your mentioned use case..As you have
mentioned, you will have to define the alias and subscriptions inline as in
the application definition.

Thanks,
Reka

>
>
> Th
>
>
>
> *From:* Reka Thirunavukkarasu [mailto:reka@wso2.com]
> *Sent:* Monday, December 08, 2014 12:22 PM
>
> *To:* dev
> *Subject:* Re: Global Deployment Policy for the Application
>
>
>
> Hi Martin,
>
>
>
> On Tue, Dec 9, 2014 at 12:46 AM, Martin Eppel (meppel) <me...@cisco.com>
> wrote:
>
>  Resending it in case you missed it
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
> *From:* Martin Eppel (meppel)
> *Sent:* Friday, December 05, 2014 1:42 PM
>
>
> *To:* dev@stratos.apache.org
> *Subject:* RE: Global Deployment Policy for the Application
>
>
>
> Hi Reka,
>
>
>
> I was looking at the attached samples and had a few questions:
>
>
>
> Did we change the group format ? In the sample you sent out there is a
> group6 and group7 defined. What is the meaning of the cartridges
> (“tomcat1”) section in the groups section for “group7”, see below ? Don’t
> we have to define “group7” separately (the zip file with the sample did not
> contain a group7.json)?
>
>
>
> Yah..We are defining the nested group as inline in order to increase the
> readability. If we are to have a nested group, then we should deploy it as
> a single group by having all the necessary nested groups's definition in
> it.
>
>
>
> Also, in the application definition we seem to duplicate  information as
> in the group6c.json (e.g. "groupMinInstances":1) ? How would the
> application_definition.json and respective group.json files look like if
> group7 also has a nested group (we do have a use case for this) ?
>
>
>
> Please refer the attached modified sample..It has the correct syntax. We
> will be specifying the min/max in the application definition only as it
> engages with the deployment. However, if you are having a nested group,
> then with the current implementation, you will have to put that nested
> group in the application definition and provide alias and other info by
> recursively going through the nested group.
>
>
>
> Thanks,
>
> Reka
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
>
>
>
>
>
>
> {
>
>     "name": "group6",
>
>     "groupMinInstances":1,
>
>     "groupMaxInstances":1,
>
>     "groups": [
>
>         {
>
>             "name": "group7",
>
>             "groupMinInstances":1,
>
>             "groupMaxInstances":1,
>
>             "cartridges": [
>
>                 "tomcat1"
>
>             ]
>
>         }
>
>
>
>     ],
>
>     "cartridges": [
>
>         "tomcat2"
>
>     ],
>
>     "dependencies": {
>
>         "startupOrders": [
>
>             "group.group7,cartridge.tomcat2"
>
>         ],
>
>         "terminationBehaviour": "terminate-all"
>
>     }
>
> }
>
>
>
> *From:* Martin Eppel (meppel)
> *Sent:* Friday, December 05, 2014 11:49 AM
> *To:* dev@stratos.apache.org
> *Subject:* RE: Global Deployment Policy for the Application
>
>
>
> Thanks Reka,
>
>
>
>
>
>
>
> *From:* Reka Thirunavukkarasu [mailto:reka@wso2.com <re...@wso2.com>]
> *Sent:* Friday, December 05, 2014 11:43 AM
> *To:* dev
> *Subject:* Re: Global Deployment Policy for the Application
>
>
>
> 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) <me...@cisco.com>
> 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:* dev@stratos.apache.org
> *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:reka@wso2.com <re...@wso2.com>]
> *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
>
>
>



-- 
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007

RE: Global Deployment Policy for the Application

Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
Hi Reka,

So if I try to model the following (real use case) with 2 levels of nested groups and the startup dependencies tomcat3 -> group8 -> tomcat1 ->group7 – tomcat2 -> group6

it will be defined as follows (see inline definition for 2nd level of nesting -> group8 in bold) :

I assume that similarly I have to define the alias and subscriptions info inline in the application definition.

{
    "name": "group6",
    "groups": [
        {
            "name": "group7",
"groups": [
                      {
                        "name": "group8",
                         "cartridges": [
                         "tomcat3"
                                    ]
                  }
            ],
            "cartridges": [
                "tomcat1"
            ],

           "dependencies": {
              "startupOrders": [
               "group.group8,cartridge.tomcat1"
               ],
              "terminationBehaviour": "terminate-all"
         }

        }

    ],
    "cartridges": [
        "tomcat2"
    ],
    "dependencies": {
        "startupOrders": [
            "group.group7,cartridge.tomcat2"
        ],
        "terminationBehaviour": "terminate-all"
    }
}


Th

From: Reka Thirunavukkarasu [mailto:reka@wso2.com]
Sent: Monday, December 08, 2014 12:22 PM
To: dev
Subject: Re: Global Deployment Policy for the Application

Hi Martin,

On Tue, Dec 9, 2014 at 12:46 AM, Martin Eppel (meppel) <me...@cisco.com>> wrote:
Resending it in case you missed it

Thanks

Martin

From: Martin Eppel (meppel)
Sent: Friday, December 05, 2014 1:42 PM

To: dev@stratos.apache.org<ma...@stratos.apache.org>
Subject: RE: Global Deployment Policy for the Application

Hi Reka,

I was looking at the attached samples and had a few questions:

Did we change the group format ? In the sample you sent out there is a group6 and group7 defined. What is the meaning of the cartridges (“tomcat1”) section in the groups section for “group7”, see below ? Don’t we have to define “group7” separately (the zip file with the sample did not contain a group7.json)?

Yah..We are defining the nested group as inline in order to increase the readability. If we are to have a nested group, then we should deploy it as a single group by having all the necessary nested groups's definition in it.

Also, in the application definition we seem to duplicate  information as in the group6c.json (e.g. "groupMinInstances":1) ? How would the application_definition.json and respective group.json files look like if group7 also has a nested group (we do have a use case for this) ?

Please refer the attached modified sample..It has the correct syntax. We will be specifying the min/max in the application definition only as it engages with the deployment. However, if you are having a nested group, then with the current implementation, you will have to put that nested group in the application definition and provide alias and other info by recursively going through the nested group.

Thanks,
Reka

Thanks

Martin




{
    "name": "group6",
    "groupMinInstances":1,
    "groupMaxInstances":1,
    "groups": [
        {
            "name": "group7",
            "groupMinInstances":1,
            "groupMaxInstances":1,
            "cartridges": [
                "tomcat1"
            ]
        }

    ],
    "cartridges": [
        "tomcat2"
    ],
    "dependencies": {
        "startupOrders": [
            "group.group7,cartridge.tomcat2"
        ],
        "terminationBehaviour": "terminate-all"
    }
}

From: Martin Eppel (meppel)
Sent: Friday, December 05, 2014 11:49 AM
To: dev@stratos.apache.org<ma...@stratos.apache.org>
Subject: RE: Global Deployment Policy for the Application

Thanks Reka,



From: Reka Thirunavukkarasu [mailto:reka@wso2.com]
Sent: Friday, December 05, 2014 11:43 AM
To: dev
Subject: Re: Global Deployment Policy for the Application

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) <me...@cisco.com>> 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: dev@stratos.apache.org<ma...@stratos.apache.org>
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:reka@wso2.com]
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<tel:%2B94776442007>




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




--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007


Re: Global Deployment Policy for the Application

Posted by Reka Thirunavukkarasu <re...@wso2.com>.
Hi Martin,

On Tue, Dec 9, 2014 at 12:46 AM, Martin Eppel (meppel) <me...@cisco.com>
wrote:

>  Resending it in case you missed it
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
> *From:* Martin Eppel (meppel)
> *Sent:* Friday, December 05, 2014 1:42 PM
>
> *To:* dev@stratos.apache.org
> *Subject:* RE: Global Deployment Policy for the Application
>
>
>
> Hi Reka,
>
>
>
> I was looking at the attached samples and had a few questions:
>
>
>
> Did we change the group format ? In the sample you sent out there is a
> group6 and group7 defined. What is the meaning of the cartridges
> (“tomcat1”) section in the groups section for “group7”, see below ? Don’t
> we have to define “group7” separately (the zip file with the sample did not
> contain a group7.json)?
>

Yah..We are defining the nested group as inline in order to increase the
readability. If we are to have a nested group, then we should deploy it as
a single group by having all the necessary nested groups's definition in
it.

>
>
> Also, in the application definition we seem to duplicate  information as
> in the group6c.json (e.g. "groupMinInstances":1) ? How would the
> application_definition.json and respective group.json files look like if
> group7 also has a nested group (we do have a use case for this) ?
>

Please refer the attached modified sample..It has the correct syntax. We
will be specifying the min/max in the application definition only as it
engages with the deployment. However, if you are having a nested group,
then with the current implementation, you will have to put that nested
group in the application definition and provide alias and other info by
recursively going through the nested group.

Thanks,
Reka

>
>
> Thanks
>
>
>
> Martin
>
>
>
>
>
>
>
>
>
> {
>
>     "name": "group6",
>
>     "groupMinInstances":1,
>
>     "groupMaxInstances":1,
>
>     "groups": [
>
>         {
>
>             "name": "group7",
>
>             "groupMinInstances":1,
>
>             "groupMaxInstances":1,
>
>             "cartridges": [
>
>                 "tomcat1"
>
>             ]
>
>         }
>
>
>
>     ],
>
>     "cartridges": [
>
>         "tomcat2"
>
>     ],
>
>     "dependencies": {
>
>         "startupOrders": [
>
>             "group.group7,cartridge.tomcat2"
>
>         ],
>
>         "terminationBehaviour": "terminate-all"
>
>     }
>
> }
>
>
>
> *From:* Martin Eppel (meppel)
> *Sent:* Friday, December 05, 2014 11:49 AM
> *To:* dev@stratos.apache.org
> *Subject:* RE: Global Deployment Policy for the Application
>
>
>
> Thanks Reka,
>
>
>
>
>
>
>
> *From:* Reka Thirunavukkarasu [mailto:reka@wso2.com <re...@wso2.com>]
> *Sent:* Friday, December 05, 2014 11:43 AM
> *To:* dev
> *Subject:* Re: Global Deployment Policy for the Application
>
>
>
> 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) <me...@cisco.com>
> 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:* dev@stratos.apache.org
> *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:reka@wso2.com <re...@wso2.com>]
> *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

RE: Global Deployment Policy for the Application

Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
Resending it in case you missed it

Thanks

Martin

From: Martin Eppel (meppel)
Sent: Friday, December 05, 2014 1:42 PM
To: dev@stratos.apache.org
Subject: RE: Global Deployment Policy for the Application

Hi Reka,

I was looking at the attached samples and had a few questions:

Did we change the group format ? In the sample you sent out there is a group6 and group7 defined. What is the meaning of the cartridges (“tomcat1”) section in the groups section for “group7”, see below ? Don’t we have to define “group7” separately (the zip file with the sample did not contain a group7.json)?

Also, in the application definition we seem to duplicate  information as in the group6c.json (e.g. "groupMinInstances":1) ? How would the application_definition.json and respective group.json files look like if group7 also has a nested group (we do have a use case for this) ?

Thanks

Martin




{
    "name": "group6",
    "groupMinInstances":1,
    "groupMaxInstances":1,
    "groups": [
        {
            "name": "group7",
            "groupMinInstances":1,
            "groupMaxInstances":1,
            "cartridges": [
                "tomcat1"
            ]
        }

    ],
    "cartridges": [
        "tomcat2"
    ],
    "dependencies": {
        "startupOrders": [
            "group.group7,cartridge.tomcat2"
        ],
        "terminationBehaviour": "terminate-all"
    }
}

From: Martin Eppel (meppel)
Sent: Friday, December 05, 2014 11:49 AM
To: dev@stratos.apache.org<ma...@stratos.apache.org>
Subject: RE: Global Deployment Policy for the Application

Thanks Reka,



From: Reka Thirunavukkarasu [mailto:reka@wso2.com]
Sent: Friday, December 05, 2014 11:43 AM
To: dev
Subject: Re: Global Deployment Policy for the Application

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) <me...@cisco.com>> 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: dev@stratos.apache.org<ma...@stratos.apache.org>
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:reka@wso2.com]
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<tel:%2B94776442007>




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


RE: Global Deployment Policy for the Application

Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
Hi Reka,

I was looking at the attached samples and had a few questions:

Did we change the group format ? In the sample you sent out there is a group6 and group7 defined. What is the meaning of the cartridges (“tomcat1”) section in the groups section for “group7”, see below ? Don’t we have to define “group7” separately (the zip file with the sample did not contain a group7.json)?

Also, in the application definition we seem to duplicate  information as in the group6c.json (e.g. "groupMinInstances":1) ? How would the application_definition.json and respective group.json files look like if group7 also has a nested group (we do have a use case for this) ?

Thanks

Martin



{
    "name": "group6",
    "groupMinInstances":1,
    "groupMaxInstances":1,
    "groups": [
        {
            "name": "group7",
            "groupMinInstances":1,
            "groupMaxInstances":1,
            "cartridges": [
                "tomcat1"
            ]
        }

    ],
    "cartridges": [
        "tomcat2"
    ],
    "dependencies": {
        "startupOrders": [
            "group.group7,cartridge.tomcat2"
        ],
        "terminationBehaviour": "terminate-all"
    }
}

From: Martin Eppel (meppel)
Sent: Friday, December 05, 2014 11:49 AM
To: dev@stratos.apache.org
Subject: RE: Global Deployment Policy for the Application

Thanks Reka,



From: Reka Thirunavukkarasu [mailto:reka@wso2.com]
Sent: Friday, December 05, 2014 11:43 AM
To: dev
Subject: Re: Global Deployment Policy for the Application

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) <me...@cisco.com>> 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: dev@stratos.apache.org<ma...@stratos.apache.org>
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:reka@wso2.com]
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<tel:%2B94776442007>




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


RE: Global Deployment Policy for the Application

Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
Thanks Reka,



From: Reka Thirunavukkarasu [mailto:reka@wso2.com]
Sent: Friday, December 05, 2014 11:43 AM
To: dev
Subject: Re: Global Deployment Policy for the Application

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) <me...@cisco.com>> 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: dev@stratos.apache.org<ma...@stratos.apache.org>
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:reka@wso2.com]
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<tel:%2B94776442007>




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


Re: Global Deployment Policy for the Application

Posted by Reka Thirunavukkarasu <re...@wso2.com>.
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) <me...@cisco.com>
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:* dev@stratos.apache.org
> *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:reka@wso2.com <re...@wso2.com>]
> *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

RE: Global Deployment Policy for the Application

Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
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: dev@stratos.apache.org
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:reka@wso2.com]
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<tel:%2B94776442007>