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
