On Tue, Oct 28, 2014 at 1:48 PM, Reka Thirunavukkarasu <r...@wso2.com> wrote:
> Hi > > On Tue, Oct 28, 2014 at 1:16 PM, Isuru Haththotuwa <isu...@apache.org> > wrote: > >> Thanks Reka for starting this Thread. >> >> Found two issues related to undeploying an Application: >> 1. https://issues.apache.org/jira/browse/STRATOS-918 - Fixed now. >> >> 2. Undeploying an Application doesn't remove it properly until the >> Member is activated. Looking in to this now. >> > > > We will need this fix for the member fault as well. If cluster monitor > starts a member upon member fault before the whole cluster termination, > then that cluster monitor is becoming active. Hence not going to terminated > state. Looking into that now.. > What is the State Transition in this case? Is it Terminating to Active? If so we might be able to generically handle this, since its a invalid state Transfer and mark the cluster as Invalid, and then terminate. For this, we need to introduce a new error state to cluster statuses. WDYT? > > Thanks, > Reka > > > >> >> On Tue, Oct 28, 2014 at 1:11 PM, Reka Thirunavukkarasu <r...@wso2.com> >> wrote: >> >>> Hi all, >>> >>> This is to update the testing Developer Preview-3 for the end to end >>> work flow. Since we have introduced the termination behaviour, we are >>> executing the following steps to verify flow. >>> >>> * Deploy an composite application with nested groups >>> * Autoscaler wil bring them using defined startup order >>> * Application will become Active >>> >>> Case 1: >>> >>> * Terminate one cluster's VM from IaaS (where this cluster is >>> *independent* from all other siblings) >>> * Nothing will happen to parents >>> * Cluster eventually become active. >>> >>> This is working fine. >>> >>> Case 2: >>> >>> * Terminate one cluster's VM from IaaS (where this cluster is >>> *dependent* on some siblings) >>> * It will notify the parent about inActive state >>> * Parent will behave according its specified termination behaviour and >>> notify its parent >>> * When this notification stops where a parent has *kill-none or at >>> application level, *that parent will push all the children to be >>> terminated. >>> * Once all the children are terminated from the sub section, that parent >>> will bring them in parallel. >>> >>> Finalising this by identifying issues. >>> >>> Case 3: >>> >>> * Unsubscribing from application >>> - all the cluster will be marked as terminated and they will >>> gradually terminated.. >>> - once all the clusters are terminated, parent will be terminated >>> - Eventually application will be terminated and send the application >>> terminated event >>> - all others act upon application terminated event and remove the >>> application related information from their side. >>> >> >>> The above is working fine now.. >>> >>> - Metadata service will also remove app details (We are testing this) >>> >>> FYI: >>> All the identified sibling to be terminated, will be terminated in >>> parallel as of now. We are not maintaining any order when terminating as i >>> explained in the earlier mail. >>> >>> Isuruh/Udara, can you also add, if i miss any testing steps? >>> >>> Thanks, >>> Reka >>> >>> -- >>> Reka Thirunavukkarasu >>> Senior Software Engineer, >>> WSO2, Inc.:http://wso2.com, >>> Mobile: >>> +94776442007 >>> >>> -- >>> <%2B94776442007> >>> Thanks and Regards, >>> >>> Isuru H. >>> <%2B94776442007> >>> +94 716 358 048 <%2B94776442007>* <http://wso2.com/>* >>> >>> >>> * <http://wso2.com/>* >>> >>> >>> > > > -- > Reka Thirunavukkarasu > Senior Software Engineer, > WSO2, Inc.:http://wso2.com, > Mobile: +94776442007 > > -- > <%2B94776442007> > Thanks and Regards, > > Isuru H. > <%2B94776442007> > +94 716 358 048 <%2B94776442007>* <http://wso2.com/>* > > > * <http://wso2.com/>* > > >
