Hi Martin, Thanks for bringing this up.
On Wed, Oct 29, 2014 at 2:13 AM, Martin Eppel (meppel) <mep...@cisco.com> wrote: > Hi Reka, > > > > Eventually termination has to follow (in reverse order) the startup > sequence: > > > > If A depends on B, B on C (startup sequence first C, second B, third A) > > > > And B is getting faulty (leaves active state), > > > > we have to > > > > with termination flag == kill_dependents: terminate A > > > > with termination flag == kill_all: terminate first A, and second C (to > maintain startup order) > > > > with termination flag == kill_none”: terminate none > Yah..This will definitely be an improvement to the termination behaviour. As i discussed in the mail "[Grouping][Part-2] Handling termination Behaviour in Composite Application Monitor Hierarchy", as of now we are supporting terminating dependents or all in parallel. We will consider this terminate the clusters using startup order as time permits. Do you have any real use case where it requires terminating the VMs using startup order? Since one of the VM of B becomes faulty and it is not in the correct startup order (it is started after A), do we still need to consider the startup order for the rest of the dependent VMs? Sorry, if i have misunderstood.. Ad case 2.) > > > > The scenario should work as follows: > > > > We have a cluster A and a cluster B (all in the same group). > > > Cluster A depends on cluster B to be active (dependency flag is set to > kill_dependents). > > > > To test, we terminate a VM from cluster B, which should set cluster B > inactive and the group and the parent (group or application) will be > notified. > > > > Since cluster B is inactive (and I assume all other VMs in the cluster as > well ?) cluster A will be terminated as well. > Correct ? > Yah. We have done the similar implementation to terminate the dependent cluster. Thanks, Reka > > > Btw, > > > > I attached the initial document for grouping which describes the start / > stopping sequences, (see section “Core Behaviour: Starting and Stopping”) > > > > Thanks > > > > Martin > > > > *From:* Reka Thirunavukkarasu [mailto:r...@wso2.com] > *Sent:* Tuesday, October 28, 2014 12:41 AM > *To:* dev > *Cc:* Martin Eppel (meppel); Isuru Haththotuwa; Udara Liyanage > *Subject:* [Grouping] Testing update of Developer Preview-3 > > > > 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 > > > -- Reka Thirunavukkarasu Senior Software Engineer, WSO2, Inc.:http://wso2.com, Mobile: +94776442007
