OK, I think we are close. In the following reply, I am only concerned with the users view, not any Stratos internal concepts or names.
I define an “application instance” to be something which is created in response to combining an application.json (which contains references to named deployment policies, one per subscribableInfo) with a set of deployment policies which match the references. These deployment policies will have been preloaded into Stratos. As you say “we cannot switch deployment policies of an application once it is deployed. However if needed we can create a new application with a new set of deployment policies”. So to avoid doubt… · An application instance must, by necessity, take a snapshot of all the policies referred to as the instance is created. Not doing so would cause confusion if the deployment policies are later updated. o Note: this does not preclude later having the ability to modify the snapshot (e.g. min/max instance values and so on). o I assume the same snapshotting is needed for the autoscaling policies. o This does imply that it has to be possible to “show” the current state of the application and its snapshotted policies for debugging purposes etc. · After the instance is deployed, the deployment (and autoscaling) policies may be changed without affecting the existing instance. Is that correct? Thanks, Shaheed P.S. Do send the .jsons when you have them. From: Imesh Gunaratne [mailto:im...@apache.org] Sent: 15 February 2015 03:52 To: Shaheedur Haque (shahhaqu); dev Subject: Re: 4.1 deployment policy questions Hi Shaheed, On Sun, Feb 15, 2015 at 12:09 AM, Shaheedur Haque (shahhaqu) <shahh...@cisco.com<mailto:shahh...@cisco.com>> wrote: Imesh, Gayan, I look forward to the updated JSON samples; they will no doubt help reduce confusion. Yes we will send this ASAP. 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). Since an application is similar to a subscription in 4.0.0, we cannot switch deployment policies of an application once it is deployed. However if needed we can create a new application with a new set of deployment policies. • 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? Yes this is possible but it is still not implemented. We could update a deployment policy in runtime and add the new network partition to it. Thereafter we need to decide whether to apply this change to all the running applications or some specific ones. Depending on the decision, a new API method can be exposed to apply a change in a deployment policy to selected set of applications using it. Thanks -- Imesh Gunaratne Technical Lead, WSO2 Committer & PMC Member, Apache Stratos
