Hi Imesh, I have done the followings as part of the effort in this modification.
- implemented network partition management logic in CC and updated relevant rest APIs and Service Clients - implemented proper deployment policy validation - fixed authorization action in some rest APIs Network partition management and deployment policy management are now working end-to-end with proper validations. Refer [1] for more detail on this. I am now looking into the changes needs to be done at Autoscaler. Will update the progress on this thread. 1. [Discuss] Deployment policy needs to be validated Thanks. On Tue, Feb 17, 2015 at 8:32 PM, Imesh Gunaratne <[email protected]> wrote: > Hi Raj/Sajith, > > Appreciate if you can provide an update on the progress we have made so > far with this modification. > > Thanks > > On Sun, Feb 15, 2015 at 10:40 PM, Imesh Gunaratne <[email protected]> > wrote: > >> Hi Shaheed, >> >> Please find comments inline: >> >> On Sun, Feb 15, 2015 at 8:03 PM, Shaheedur Haque (shahhaqu) < >> [email protected]> wrote: >> >>> 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. >>> >>> >>> >> Thanks for the explanation! Yes I completely agree with your view on >> this, we will need to expose an application instance id to the user when we >> introduce application templates. >> >> >>> 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. >>> >> +1 Yes AFAIK this functionality is not there at the moment, we will add >> it. >> >>> o Note: this does not preclude later having the ability to modify >>> the snapshot (e.g. min/max instance values and so on). >>> >> Yes, as I mentioned in the previous response, I also would like to have >> the ability to update deployment and autoscaling policies with/without >> affecting deployed applications. >> >>> o I assume the same snapshotting is needed for the autoscaling >>> policies. >>> >> Yes indeed, autoscaling policies also need to be snapshotted. >> >>> 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. >>> >> +1 >> >>> · After the instance is deployed, the deployment (and >>> autoscaling) policies may be changed without affecting the existing >>> instance. >>> >> Yes, I would like to have the capability to either apply changes to >> deployed applications or not to apply them. If so users could use this >> feature as they wish. >> >> Thanks, >> Imesh >> > > > > -- > 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
