You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Rajkumar Rajaratnam <ra...@wso2.com> on 2014/10/15 05:28:22 UTC
Manual scaling effects are not persisted
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
Re: Manual scaling effects are not persisted
Posted by Lakmal Warusawithana <la...@wso2.com>.
This is not only related to manual scaling, we should have some mechanism
to persist associate polices (and run time changes) with cartridge
subscription. Currently it does not required because we did not allow to
change policies (run time update for policies) per subscription. But since
we are planning to allow this we need some model to persist policies (and
all other parameters), run time policy changes (min, threshold values etc).
On Wed, Oct 15, 2014 at 4:42 PM, Rajkumar Rajaratnam <ra...@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 <rajkumarr@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 <ra...@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
>
--
Lakmal Warusawithana
Vice President, Apache Stratos
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: Manual scaling effects are not persisted
Posted by Lahiru Sandaruwan <la...@wso2.com>.
Hi,
It seems we need to introduce cluster context(which will be persisted) for
keeping these runtime changes to policies and also the run time data such
as required count.
I will work on this.
Thanks.
On Sat, Oct 18, 2014 at 10:58 AM, Imesh Gunaratne <im...@apache.org> wrote:
> 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 <ra...@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 <
>>> rajkumarr@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 <ra...@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
>
--
--
Lahiru Sandaruwan
Committer and PMC member, Apache Stratos,
Senior Software Engineer,
WSO2 Inc., http://wso2.com
lean.enterprise.middleware
email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
Re: Manual scaling effects are not persisted
Posted by Imesh Gunaratne <im...@apache.org>.
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 <ra...@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 <rajkumarr@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 <ra...@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
Re: Manual scaling effects are not persisted
Posted by Rajkumar Rajaratnam <ra...@wso2.com>.
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 <ra...@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 <ra...@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
Re: Manual scaling effects are not persisted
Posted by Imesh Gunaratne <im...@apache.org>.
I do not think we need to specifically handle this, manual scaling also
need to take the same path as the standard scaling decision.
On Wed, Oct 15, 2014 at 10:03 AM, Rajkumar Rajaratnam <ra...@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 <ra...@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
Re: Manual scaling effects are not persisted
Posted by Rajkumar Rajaratnam <ra...@wso2.com>.
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 <ra...@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