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.
On Wed, Jul 9, 2014 at 4:33 PM, Reka Thirunavukkarasu <[email protected]> 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 > > > -- Udara Liyanage Software Engineer WSO2, Inc.: http://wso2.com lean. enterprise. middleware web: http://udaraliyanage.wordpress.com phone: +94 71 443 6897
