Hi Shaheedur, Please find my comments on blue.
Thanks, Gayan On Fri, Feb 13, 2015 at 3:27 PM, Shaheedur Haque (shahhaqu) < shahh...@cisco.com> wrote: > Thanks, I must have missed this thread before. CIL…but remember that I > am talking conceptually only as I don’t know the implementation. > > > > *From:* Imesh Gunaratne [mailto:im...@apache.org] > *Sent:* 13 February 2015 09:28 > *To:* dev; Shaheedur Haque (shahhaqu) > *Subject:* Re: 4.1 deployment policy questions > > > > [Adding Shaheed] > > > > On Fri, Feb 13, 2015 at 8:31 AM, Imesh Gunaratne <im...@apache.org> wrote: > > I agree with Udara. We could take the following approach to improve the > efficiency: > > > > 1. Implement deployment policy management logic and service methods in CC > without affecting any other modules > > 2. Implement dpeloyment policy management REST API methods, still this > would not affect any other modules > > > > [srh] I take it this means that deployment policies will be loaded ahead > of time, just like in 4.0? That would be great, but then I don’t understand > how your concept of multiple application instances will work: > > > > - Each subscribableInfo points to one deploymentPolicy, so there might be > more > > than one deploymentPolicy for the application as a whole. > > > > - According to the **current** 4.1 workflow, the curl command specifies > the name > > for the application and a single –b .json argument, therefore the –b must * > *contain** > > all the named deploymentPolicy’s. > > > > - Different application instances must have different deployment policies, > so they > > Must use .json files with different content but the same deploymentPolicy > names. > > > > This contradicts having globally defined deployment polciies loaded ahead > of time, or did I miss something? > [Gayan] Yeah. We are define the deploy policy in globally. In the cartridge level we are define which deployment policy we are using for the cartridge under subscribeInfo. When the application deployment we can specify what is the network partitions which we are used with the application with the following json. { "networkPartition":[ { "id":"network-partition-1", "activeByDefault":"true" }, { "id":"network-partition-2", "activeByDefault":"false" } ] } Here I think we need a network partition validation with the deployment policies which we are using in the application.(Defined in all the cartridges of the application) Deployment policy with "activeByDefault=true" is the deployment policy which we used to deploy application. As we define the deploy policy in globally we can share the deploy policy among the different applications. > > > > 3. Provide API method details to allow UI and CLI to be updated in parallel > > 4. Update application bean and definition to refer deployment policy ids, > this can be done in parallel > > 5. Once 1, 2 and 4 are done, remove Application Policy and Chid Policy > classes in Autoscaler > > 6. Rename previous Deployment Policy class in Autoscaler to Application > Policy and add the new definition > > > > [srh] Please clarify what these “new definitions” are. Please realise that > it is simply not possible to review things which are changing without the > details of the proposal. > > > > Thanks, Shaheed > Deployment Policy definition(Globally available) { "id": "deployment-policy-2", "networkPartition": [ { "id": "network-partition-1", "partitionAlgo": "one-after-another", "partitions": [ { "id": "partition-1", "max": 5 } ] } ] } Application deployment policy(Which is pass with the application deployment) { "networkPartition":[ { "id":"network-partition-1", "activeByDefault":"true" }, { "id":"network-partition-2", "activeByDefault":"false" } ] } > > 7. Fix references to previous Deployment Policy in Autoscaler > > > > Thanks > > > > On Thu, Feb 12, 2015 at 11:20 PM, Udara Liyanage <ud...@wso2.com> wrote: > > Hi, > > I started working on new branch. However it has lot of compilation > failures. I started fixing few, but there are many. It is true that we are > changing/adding some functionality which it is OK to functions not to work > properly. But we can avoid compilation issues IMO. We can change back end > first and then fix Rest API or some way. > > > > > > > -- > > Imesh Gunaratne > > > > Technical Lead, WSO2 > > Committer & PMC Member, Apache Stratos > > > > > > -- > > Imesh Gunaratne > > > > Technical Lead, WSO2 > > Committer & PMC Member, Apache Stratos > -- Gayan Gunarathne Technical Lead WSO2 Inc. (http://wso2.com) email : gay...@wso2.com | mobile : +94 766819985
