The other concern is what would a user do upon an alert? Is that of a user's control? May be asking to send a mail to system admins? IMO this is some issue with the stratos and may be what should we do is to alert the system admins (dev-ops etc.).
On Thu, Jan 9, 2014 at 10:50 AM, Nirmal Fernando <[email protected]>wrote: > Yes, may be in the subscription UI, we could add an alert. But, we should > come up with a design on how to get it to there. > > > On Thu, Jan 9, 2014 at 10:36 AM, Isuru Haththotuwa <[email protected]>wrote: > >> On Thu, Jan 9, 2014 at 10:25 AM, Nirmal Fernando >> <[email protected]>wrote: >> >>> Hi Lahiru, >>> >>> I'm sorry, but I don't get your point here and also I don't understand >>> how the proposed solution would solve this problem (what if there's an >>> error and that made member activation event to not sent ever). >>> >>> I wonder whether we need to be concerned on this kind of issues. >>> >> >> I agree that this is an optimization. But if there is an error, IMHO it >> is better to notify the user (maybe printing a log statement) that the >> activation is not received continuously for the last n number of instances >> spawned, without keep on terminating and re-spawning. >> >>> >>> >>> On Thu, Jan 9, 2014 at 10:00 AM, Isuru Haththotuwa <[email protected]>wrote: >>> >>>> +1. We can make the waiting time x2 each time, but there should be a >>>> ceiling value as well. >>>> >>>> >>>> On Wed, Jan 8, 2014 at 11:28 PM, Lahiru Sandaruwan <[email protected]>wrote: >>>> >>>>> Hi all, >>>>> >>>>> Currently if an instance is not joined after a timeout, we will >>>>> terminate the instance and it will be removed from the pending state. >>>>> Then the Autoscaler will decide to spawn more instances according to >>>>> the rules, to cover terminated instances. >>>>> If there is an error which blocks sending member activate event( in >>>>> the cartridge, network or at any other place), system will be terminating >>>>> and starting instances continuously, which is an utter waste of resources. >>>>> >>>>> So I suggest following scenario, >>>>> >>>>> We keep a count of unactivated instances per cluster. If this count >>>>> exceeds a limit( say 3 - should be configurable), we will increase waiting >>>>> time on the next instance activation. May be we keep increasing. >>>>> We can reset the count when ever a member activation received. >>>>> >>>>> Wdyt? >>>>> >>>>> Thanks. >>>>> >>>>> Sent from my mobile. >>>>> >>>> >>>> >>>> >>>> -- >>>> Thanks and Regards, >>>> >>>> Isuru H. >>>> Software Engineer, WSO2 Inc. >>>> +94 716 358 048* <http://wso2.com/>* >>>> >>>> >>>> >>> >>> >>> -- >>> Best Regards, >>> Nirmal >>> >>> Nirmal Fernando. >>> PPMC Member & Committer of Apache Stratos, >>> Senior Software Engineer, WSO2 Inc. >>> >>> Blog: http://nirmalfdo.blogspot.com/ >>> >> >> >> >> -- >> Thanks and Regards, >> >> Isuru H. >> Software Engineer, WSO2 Inc. >> +94 716 358 048* <http://wso2.com/>* >> >> >> > > > -- > Best Regards, > Nirmal > > Nirmal Fernando. > PPMC Member & Committer of Apache Stratos, > Senior Software Engineer, WSO2 Inc. > > Blog: http://nirmalfdo.blogspot.com/ > -- Best Regards, Nirmal Nirmal Fernando. PPMC Member & Committer of Apache Stratos, Senior Software Engineer, WSO2 Inc. Blog: http://nirmalfdo.blogspot.com/
