stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manula Chathurika Thantriwatte <manu...@wso2.com>
Subject Re: Global Deployment Policy for the Application
Date Mon, 08 Dec 2014 10:59:09 GMT
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) <meppel@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 <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) <meppel@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 <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
>
>
>
>
>
>
>
> --
>
> 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/

Mime
View raw message