stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shaheedur Haque (shahhaqu)" <shahh...@cisco.com>
Subject RE: [Discuss] Defining Cloud Bursting Pattens in Application Policy
Date Thu, 05 Mar 2015 21:18:51 GMT

LGTM....

________________________________
From: Imesh Gunaratne [imesh@apache.org]
Sent: 04 March 2015 11:59
To: dev; Shaheedur Haque (shahhaqu); Lakmal Warusawithana
Subject: [Discuss] Defining Cloud Bursting Pattens in Application Policy

Hi Devs,

Shaheed raised an issue related to Application Policy definition where we define an attribute
called "activeByDefault" to mark the network partitions which will be used for initially spawning
application instances.

The concern was to either remove this attribute and only send the active by default network
partitions in the list, or to introduce a capability to define an algorithm to traverse among
network partitions. I think it would be better to go with the second option for this purpose
as it provides more flexibility for the user. Here the algorithms should be implemented using
an interface and should be pluggable.

Modification 1:
If we do this I think we can change the application policy definition as follows:

{
    "id": "application-policy-1",
    "algorithm":"one-after-another",
    "networkPartitions":[
        "network-partition-1",
        "network-partition-2",
        "network-partition-3",
        "network-partition-4"
    ],
    "properties":[
        {
            "key1" : "value1"
        },
        {
            "key2" : "value2"
        }
    ]
}

The algorithm value ("one-after-another") to its class name mapping can be done in autoscaler
configuration file. If the algorithm class needs any additional values those can be passed
via the properties field.

Modification 2:
In addition to this we should be able to manage Application Policies in global level. If so
we can reuse Application Policies for different applications.

Modification 3:
According to this model the application deployment API method would change as follows:

Deploy Application API Method:
POST /api/applications/{application-id}/deploy/{application-policy-id}

UnDeploy Application API method:
POST /api/applications/{application-id}/undeploy

I'm +1 to incorporate these changes for the 4.1.0-beta developer preview. Please review and
add your thoughts.

Thanks

--
Imesh Gunaratne

Technical Lead, WSO2
Committer & PMC Member, Apache Stratos

Mime
View raw message