Hi Shaheed, Please find comments inline:
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: > > > 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
