Hi Isuru, +1
Please see a questions / comments inline Thanks Martin From: [email protected] [mailto:[email protected]] 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>
