Hi, @Raj: What I pointed out is a design issue. Each time we introduce a new feature we should not introduce new persistence logic unless unavoidable, rather persistence should happen centrally.
In this scenario when we update the subscription it should go through a common flow and update the in memory data structure and persist the changes. @Lakmal: Yes definitely, will introduce a new feature to update policies. https://issues.apache.org/jira/browse/STRATOS-896 Thanks On Wed, Oct 15, 2014 at 4:42 PM, Rajkumar Rajaratnam <rajkum...@wso2.com> wrote: > Hi Imesh, > > On Wed, Oct 15, 2014 at 4:26 PM, Imesh Gunaratne <im...@apache.org> wrote: > >> I do not think we need to specifically handle this, manual scaling also >> need to take the same path as the standard scaling decision. >> > > Hmm.. In manual scaling what we are doing is increasing the min count > right? Basically we are modifying the cluster object which is already > created and added to the topology. Please be kind enough to explain me if I > got it wrong. How it can take the same path as standard scaling? > > Thanks. > >> >> On Wed, Oct 15, 2014 at 10:03 AM, Rajkumar Rajaratnam <rajkum...@wso2.com >> > wrote: >> >>> Or else, we can have an API at CC side to update clusters and let CC to >>> publish ClusterUpdated event to topology topic. AS can simply listen to >>> this event and update the cluster context accordingly. Then we don't need >>> to introduce a new topic for AS to publish events and AS is already >>> listening to topology topic. IMO, this is a good approach. >>> >>> Wdyt? >>> >>> >>> On Wednesday, October 15, 2014, Rajkumar Rajaratnam <rajkum...@wso2.com> >>> wrote: >>> >>>> Hi, >>>> >>>> As you know, we are now supporting manual scaling for docker >>>> containers. Autoscaler has an API to update cluster properties like min >>>> replicas of a particular cluster. >>>> >>>> void updateClusterMonitor(String clusterId, Properties properties) >>>> throws InvalidArgumentException; >>>> >>>> We are not persisting anything about clusters at AS side, when we >>>> shutdown stratos. When we are restarting, we are reading topology and >>>> create/populate/update cluster monitors. >>>> >>>> Hence this new value for min replicas is not persisted when we shutdown >>>> the stratos. During manual scaling the min replicas is updated only in AS >>>> side, hence if we restart the stratos, this effect will be lost. >>>> >>>> So manual scaling should impact the topology. Here is a proposed >>>> solution. >>>> >>>> AS will provide an API to update cluster monitors, that is you can >>>> update properties of a cluster like min replicas. Once this API is called >>>> AS will send a *ClusterAltered* event to CC. Once CC gets this event, >>>> it will validate the properties, update the topology and send a >>>> *ClusterUpdated* event. Once AS gets this event, AS will update the >>>> cluster context with new values for properties like min replicas. Until we >>>> get cluster updated event, AS will not alter any properties. >>>> Then everything is consistent and manual scaling effects will be >>>> persisted. >>>> >>>> wdyt? >>>> >>>> Thanks. >>>> >>>> -- >>>> Rajkumar Rajaratnam >>>> Software Engineer | WSO2, Inc. >>>> Mobile +94777568639 | +94783498120 >>>> >>> >>> >>> -- >>> Rajkumar Rajaratnam >>> Software Engineer | WSO2, Inc. >>> Mobile +94777568639 | +94783498120 >>> >>> >> >> >> -- >> Imesh Gunaratne >> >> Technical Lead, WSO2 >> Committer & PMC Member, Apache Stratos >> > > > > -- > Rajkumar Rajaratnam > Software Engineer | WSO2, Inc. > Mobile +94777568639 | +94783498120 > -- Imesh Gunaratne Technical Lead, WSO2 Committer & PMC Member, Apache Stratos
