Hi all, I have now implemented network partitions algorithms and changed application policy schema. All the above proposed modifications are done now. Changes are available in master.
Thanks. On Fri, Mar 6, 2015 at 9:26 AM, Imesh Gunaratne <[email protected]> wrote: > Thanks for the feedback Shaheed! > > On Fri, Mar 6, 2015 at 2:48 AM, Shaheedur Haque (shahhaqu) < > [email protected]> wrote: > >> >> LGTM.... >> >> ------------------------------ >> *From:* Imesh Gunaratne [[email protected]] >> *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 >> > > > > -- > Imesh Gunaratne > > Technical Lead, WSO2 > Committer & PMC Member, Apache Stratos > -- Rajkumar Rajaratnam Committer & PMC Member, Apache Stratos Software Engineer, WSO2 Mobile : +94777568639 Blog : rajkumarr.com
