Hi Reka,
I am not sure about all the use cases but I followed up with our team regarding
the termination order when we discussed it in a previous email thread (see
attached response) and it seems necessary to consider the startup order in the
termination. I’ll copy him on the email for some help with the use cases,
Hi Shaheed,
can you help us with some of use cases on Reka’s question below (maintaining
reverse startup order when terminating VMs,
quoting Reka’s question from the email thread below:
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
“
Thanks
Martin
From: Reka Thirunavukkarasu [mailto:r...@wso2.com]
Sent: Tuesday, October 28, 2014 9:57 PM
To: Martin Eppel (meppel)
Cc: dev; Isuru Haththotuwa; Udara Liyanage
Subject: Re: [Grouping] Testing update of Developer Preview-3
Hi Martin,
Thanks for bringing this up.
On Wed, Oct 29, 2014 at 2:13 AM, Martin Eppel (meppel)
<mep...@cisco.com<mailto: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<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
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007<tel:%2B94776442007>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007<tel:%2B94776442007>
--- Begin Message ---
Killing must respect the (reversed) startup order where one exists.
On Tuesday 07 Oct 2014 23:44:59 Matt Turner wrote:
Interesting question. My 2 cents is that yes, we do want them killed in
(reverse) startup order according to the dependency relationships.
On 07/10/2014 19:56, "Martin Eppel (meppel)"
<mep...@cisco.com<mailto:mep...@cisco.com>> wrote:
Hi Shaheed,
The question came up that when multiple dependencies need to be killed if there
is a requirement to kill them one by according their the dependency
relationship or if they can get terminated in parallel ?
Thanks
Martin
--- End Message ---
