+1 From: Reka Thirunavukkarasu [mailto:r...@wso2.com] Sent: Wednesday, July 09, 2014 5:43 AM To: Udara Liyanage Cc: dev; Lakmal Warusawithana; Martin Eppel (meppel); Isuru Haththotuwa Subject: Re: Composite Application Deployment and Application Monitor for Autoscaler
Hi Udara, On Wed, Jul 9, 2014 at 5:43 PM, Udara Liyanage <ud...@wso2.com<mailto:ud...@wso2.com>> wrote: Hi Reka, Currently in AS we have a cluster moniter which act on ClusterCreated events when a subscription happens. Are we going to use the same ClusterMoniter for compositeApp deployment or adding another moniter like ApplicationMoniter. We can use ApplicationMonitor for the global monitoring of a composite Application. This will get added when AS receives ApplicationCreatedEvent. We can still have the cluster monitor registered per cluster. In that case, ApplicationMonitor can send the controls to ClusterMonitor as what to do such as start, pause, terminate and etc according to startup or termination dependency characteristics of other dependents. Also, independent clusters can be monitored by Cluster Monitor without any issue..I believe, this will improve the performance than ApplicationMonitor itself evaluates all dependencies and monitors whole clusters. In that case, the decision of independent clusters might get delayed when ApplicationMonitor goes through all the clusters. WDYT? Thanks, Reka On Wed, Jul 9, 2014 at 4:33 PM, Reka Thirunavukkarasu <r...@wso2.com<mailto:r...@wso2.com>> wrote: Hi all, These are the break down that we may need to consider when deploying Composite Application and when starting an ApplicationMonitor. I have integrated the earlier subscription model with Composite Application. Please see below and provide you thoughts on this. So that we can finalize the things before the implementation. Sorry for the bit long mail.. *As discussed in the previous mail by Martin and Isuruh, now that the service group definitions are deployed independently and Composite Application will use a reference to pre-deployed service Group with autoscaling policy, deployment policy and etc. - service group definition is deployed and persisted in SM - Composite Application Deployment + This will be parsed by SM to get the already deployed service Group definition to validate and to load the information. + SM needs to validate the deployment policy and autoscale policy against cartridge Type by calling Autoscaler. + SM needs to perform any other validation as required or any logical validation + Once all validation are done, SM needs to extract subscription related information from Composite Application and persist in it. + SM needs to build the payload or pass relevant information to CC to build the payload. + SM invokes service call to CC to deploy the Composite Application with all data. + CC will persist any required data from Composite Application and build the Topology with Composite Application. In that case, it should even create a Cluster with Composite Application and build the data model. Then only, it should send the ApplicationCreatedEvent. If we don't build Cluster object with ApplicationCreatedEvent, then autoscaler has to wait for each ClusterCreatedEvent to perform the actions. In that case, autoscaler won't aware of how many ClusterCreatedEvents it should receive before starts monitoring on a Composite Application. If all the Cluster is available with Composite Application as part of ApplicationCreatedEvent, then autoscaler can start monitor and evaluate dependencies to spin the instances. * New events to the Topology -ApplicationCreatedEvent Sent after the composite Application got deployed successfully -ApplicationTerminatedEvent when composite application undeployed -GroupStartEvent After cluster/clusters in a groups gets started with an instance -GroupActivatedEvent After all the clusters in the group becomes active with the minimum member count -GroupterminatedEvent After a group terminated -GroupInMaintenanceModeEvent After a group trying to restart on of it's internal cartridge cluster or group. *Application Monitor in autoscaler - has to find out the dependencies, get the least dependent cartridge type/s or group/s and start minimum rule for them individually or in parallel according to the start up order specified. - CC has to send InstanceSpawned/GroupStartedEvent. Once instance/s activated, CC has to check the minimum no of instance count available in the Cluster from Topology, and send the GroupActivatedEvent or CC has to follow any other approach to send GroupActivatedEvent. - In the member activation or Group activation start the next least dependent cartridge type/s or group/s * Find an optimized algorithm to traverse the relation data model for the Composite Application. I assume, it will be a tree structure..Will autoscaler or LB or anyone who subscribes to Topology require this at any point? * We need to revise our relational data model according to the current Composite Application Definition. I believe, the same group with different alias may present in the relational data model more than one time. Eg: App1 | ------------------------------------------------------------------------------- | | Group1(myapp) Group2(myapp2) | | ------------------------- ------------------------ | | | | Group2(myapp3) cartridge1(mycar1) cartirdge2(mycar2) cartridge3(mycar3) Eg: Group1(myapp) - Group1 is the group name and myapp is the alias Where Group2 is getting used twice in the data model. So, we need to keep reference of Group2 more than one place. If we already did so, please ignore this. Please do add, if there is any missing items to be considered to the list. Thanks, Reka -- Reka Thirunavukkarasu Senior Software Engineer, WSO2, Inc.:http://wso2.com, Mobile: +94776442007<tel:%2B94776442007> -- Udara Liyanage Software Engineer WSO2, Inc.: http://wso2.com<http://wso2.com/> lean. enterprise. middleware web: http://udaraliyanage.wordpress.com phone: +94 71 443 6897 -- Reka Thirunavukkarasu Senior Software Engineer, WSO2, Inc.:http://wso2.com, Mobile: +94776442007<tel:%2B94776442007>
