Imesh, Gayan, I look forward to the updated JSON samples; they will no doubt help reduce confusion.
Just to comment briefly on the replies you provided. The thing I don’t understand is how you intend the “Application deployment policy(Which is pass with the application deployment)” to work over time: · Let’s say that on Monday, I define a deployment policy with network partitions A, B and C. I can see that I could use different application deployment policies to turn A or B or C on-and-off and use that to deploy the application (for example) once just to A, and then a second time to B + C. (That seems like a weird use case to me, but if you have a need for it, that is fine). · Now we get to Friday, and I have just taken a contract with D to use their resources in addition to A, B and C. My service must continue to run uninterrupted on A, B and C even as I take advantage of D. (That seems a more likely use case to me). Now what is the sequence of steps? Thanks, Shaheed From: Imesh Gunaratne [mailto:im...@apache.org] Sent: 13 February 2015 11:39 To: dev; Shaheedur Haque (shahhaqu) Subject: Re: 4.1 deployment policy questions Hi Shaheed, Please find comments inline: On Fri, Feb 13, 2015 at 3:27 PM, Shaheedur Haque (shahhaqu) <shahh...@cisco.com<mailto: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<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<mailto: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: Application instance is an internal entity which is used for replicating an application in multiple network partitions. If an application is using cartridges on multiple network partitions, application policy can be configured or netwrk partition usage. This would say whether the application needs to be deployed on all network partitions at once or do cloud bursting. - Each subscribableInfo points to one deploymentPolicy, so there might be more than one deploymentPolicy for the application as a whole. Yes that's correct. - 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. No, what we mean by application instance is bit different in the current design since there is no application template concept. Aplication instance is not an instance of an application template. Rather it is an instance of the application in a network partition. This contradicts having globally defined deployment polciies loaded ahead of time, or did I miss something? I think not, since an application in 4.1.0 is similar to a subscription in 4.0.0, deployment policies are defined at application creation time. 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. Yes sure I will prepare a document with new artifacts and share more information on that. Thanks, Shaheed Thanks -- Imesh Gunaratne Technical Lead, WSO2 Committer & PMC Member, Apache Stratos
