You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Isuru Haththotuwa <is...@apache.org> on 2014/10/24 17:28:29 UTC
[Discuss] [Service Grouping] Undeployment Process for a Composite Application
Hi Devs,
The purpose of this thread is to discuss $subject.
I identified the following workflow:
1. Application owner undeploys the app via the rest API, using
application id
2. This will be notified to CC over a service call
3. CC updates the Cluster and Application statuses to 'Inactive' in
Topology, and send the 'Application Undeployed' event
4. Upon receiving the Application Undeployed event, Autoscaler will put
the Application, Group and Cluster Monitors' statuses to 'Terminating' and
start terminating members. The monitors will get removed. Also, the
relevant events will be sent via the Application Status topic and CC will
update the Topology with the correct statuses for Clusters, Groups, etc.
5. Once everything is terminated and cleaned up, the Autoscaler sends
the 'Application Terminated' event
6. CC removed the application data from Topology upon the event
Application Terminated event, and notify the Topology listeners
WDYT?
--
Thanks and Regards,
Isuru H.
+94 716 358 048* <http://wso2.com/>*
Re: [Discuss] [Service Grouping] Undeployment Process for a Composite Application
Posted by Udara Liyanage <ud...@wso2.com>.
Hi Isuru,
Why CC set application status to Inactive? Application inactive state
refers to the state where its clusters or groups are not activated yet. May
be terminating is better, isn't it?
Touched, not typed. Erroneous words are a feature, not a typo.
Re: [Discuss] [Service Grouping] Undeployment Process for a Composite Application
Posted by Isuru Haththotuwa <is...@apache.org>.
Hi Udara and Martin,
On Fri, Oct 24, 2014 at 11:40 PM, Udara Liyanage <ud...@wso2.com> wrote:
> Touched, not typed. Erroneous words are a feature, not a typo.
> On Oct 24, 2014 10:28 PM, "Martin Eppel (meppel)" <me...@cisco.com>
> wrote:
> >
> > Hi Isuru,
> >
> >
> >
> > +1
> >
> >
> >
> > Please see a questions / comments inline
> >
> >
> >
> > Thanks
> >
> >
> >
> > Martin
> >
> >
> >
> > From: isuruh@wso2.com [mailto:isuruh@wso2.com] On Behalf Of Isuru
> Haththotuwa
> > Sent: Friday, October 24, 2014 8:28 AM
> > To: dev
> > Subject: [Discuss] [Service Grouping] Undeployment Process for a
> Composite Application
> >
> >
> >
> > Hi Devs,
> >
> > The purpose of this thread is to discuss $subject.
> >
> > I identified the following workflow:
> >
> > Application owner undeploys the app via the rest API, using application
> id
> > This will be notified to CC over a service call
> > CC updates the Cluster and Application statuses to 'Inactive' in
> Topology, and send the 'Application Undeployed' event
> > Martin> Not sure if this makes sense but I am wondering if status
> inactive necessarily should mean that an application should be undeployed.
> I could think of a (possible) future use case that we want to be able to
> deactivate an application (e.g. maintenance mode) without undeploying it,
> wdyt ? What are the application states we are currently supporting ?
>
Sorry for the confusion, my mistake. The status should corrected to
'Terminating'. Thanks a lot for pointing it out. You are correct,
Application Inactive status can happen in other cases as member errors,
etc. So we need to be able to distinguish such situations from
undeployment.
Please find mail on dev list [1] discussing possible Application States.
> At that point we can add another status InMaintainace which is handled
> differently. Created, activated, inactive, terminating and terminated are
> the available states currently.
> > Upon receiving the Application Undeployed event, Autoscaler will put the
> Application, Group and Cluster Monitors' statuses to 'Terminating' and
> start terminating members. The monitors will get removed. Also, the
> relevant events will be sent via the Application Status topic and CC will
> update the Topology with the correct statuses for Clusters, Groups, etc.
> >
> > Martin> I assume that not only application events but all the respective
> group, cluster and member topology events will be sent as well as they
> transition through the respective states, correct ?
> It should be. I get the feeling Isuru also has meant the same.
>
Yes, exactly.
[1]. [Discuss] [Service Grouping] Life Cycle of an Composite Application
> > Once everything is terminated and cleaned up, the Autoscaler sends the
> 'Application Terminated' event
> > CC removed the application data from Topology upon the event Application
> Terminated event, and notify the Topology listeners
> >
> > WDYT?
> >
> > --
> >
> > Thanks and Regards,
> >
> > Isuru H.
> >
> > +94 716 358 048
> >
>
--
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048* <http://wso2.com/>*
>
>
> * <http://wso2.com/>*
>
>
>
RE: [Discuss] [Service Grouping] Undeployment Process for a Composite Application
Posted by Udara Liyanage <ud...@wso2.com>.
Touched, not typed. Erroneous words are a feature, not a typo.
On Oct 24, 2014 10:28 PM, "Martin Eppel (meppel)" <me...@cisco.com> wrote:
>
> Hi Isuru,
>
>
>
> +1
>
>
>
> Please see a questions / comments inline
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
> From: isuruh@wso2.com [mailto:isuruh@wso2.com] On Behalf Of Isuru
Haththotuwa
> Sent: Friday, October 24, 2014 8:28 AM
> To: dev
> Subject: [Discuss] [Service Grouping] Undeployment Process for a
Composite Application
>
>
>
> Hi Devs,
>
> The purpose of this thread is to discuss $subject.
>
> I identified the following workflow:
>
> Application owner undeploys the app via the rest API, using application id
> This will be notified to CC over a service call
> CC updates the Cluster and Application statuses to 'Inactive' in
Topology, and send the 'Application Undeployed' event
> Martin> Not sure if this makes sense but I am wondering if status
inactive necessarily should mean that an application should be undeployed.
I could think of a (possible) future use case that we want to be able to
deactivate an application (e.g. maintenance mode) without undeploying it,
wdyt ? What are the application states we are currently supporting ?
At that point we can add another status InMaintainace which is handled
differently. Created, activated, inactive, terminating and terminated are
the available states currently.
> Upon receiving the Application Undeployed event, Autoscaler will put the
Application, Group and Cluster Monitors' statuses to 'Terminating' and
start terminating members. The monitors will get removed. Also, the
relevant events will be sent via the Application Status topic and CC will
update the Topology with the correct statuses for Clusters, Groups, etc.
>
> Martin> I assume that not only application events but all the respective
group, cluster and member topology events will be sent as well as they
transition through the respective states, correct ?
It should be. I get the feeling Isuru also has meant the same.
> Once everything is terminated and cleaned up, the Autoscaler sends the
'Application Terminated' event
> CC removed the application data from Topology upon the event Application
Terminated event, and notify the Topology listeners
>
> WDYT?
>
> --
>
> Thanks and Regards,
>
> Isuru H.
>
> +94 716 358 048
>
RE: [Discuss] [Service Grouping] Undeployment Process for a
Composite Application
Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
Hi Isuru,
+1
Please see a questions / comments inline
Thanks
Martin
From: isuruh@wso2.com [mailto:isuruh@wso2.com] On Behalf Of Isuru Haththotuwa
Sent: Friday, October 24, 2014 8:28 AM
To: dev
Subject: [Discuss] [Service Grouping] Undeployment Process for a Composite Application
Hi Devs,
The purpose of this thread is to discuss $subject.
I identified the following workflow:
1. Application owner undeploys the app via the rest API, using application id
2. This will be notified to CC over a service call
3. CC updates the Cluster and Application statuses to 'Inactive' in Topology, and send the 'Application Undeployed' event
Martin> Not sure if this makes sense but I am wondering if status inactive necessarily should mean that an application should be undeployed. I could think of a (possible) future use case that we want to be able to deactivate an application (e.g. maintenance mode) without undeploying it, wdyt ? What are the application states we are currently supporting ?
4. Upon receiving the Application Undeployed event, Autoscaler will put the Application, Group and Cluster Monitors' statuses to 'Terminating' and start terminating members. The monitors will get removed. Also, the relevant events will be sent via the Application Status topic and CC will update the Topology with the correct statuses for Clusters, Groups, etc.
Martin> I assume that not only application events but all the respective group, cluster and member topology events will be sent as well as they transition through the respective states, correct ?
5. Once everything is terminated and cleaned up, the Autoscaler sends the 'Application Terminated' event
6. CC removed the application data from Topology upon the event Application Terminated event, and notify the Topology listeners
WDYT?
--
Thanks and Regards,
Isuru H.
+94 716 358 048<tel:%2B94%20716%20358%20048>