On Sun, Jul 6, 2014 at 9:39 PM, Isuru Haththotuwa <isu...@apache.org> wrote:
> Hi Imesh, > > Yes, completely agree. Should have the proper documentation for this. Will > do that once we have the basic version of this feature done. > > Hi Lahiru, > > On Sun, Jul 6, 2014 at 7:50 PM, Lahiru Sandaruwan <lahi...@wso2.com> > wrote: > >> Hi Isuru, >> >> Any reason why we use MB for subscription event? We can use direct >> service call to CC IMO. >> > That is one option. But its different from the invocation we do through > the CC to spawn instances each individual service, since now there is a > startup order and a kill order, etc. Therefore, we need to have a > 'Composite Application Monitor' in Autoscaler, which will do the spinning > up, termination of instances in the particular order. For this, its easier > if we send an event from SM, so that the Autoscaler and any interested > party can act upon it. > > Furthermore, if we use CC's API, there will be several object conversions > as follows: > > JSON bean -> CC's API object -> Messaging Component Application object > (for the event) > > However, if we directly send the event from the SM itself, there will be > only one conversion: > > JSON bean -> Messaging Component Application object (for the event) > > Since Composite Application is a complex structure, with nested groups > etc., it will be better if we can reduce the conversions between these > objects. Considering all these, IMHO its better if SM sends the Composite > Application Deployed event itself. > Thanks for the clarification Isuru. But aren't we publishing all the topology related events from CC? Does this event use a different topic? > > >> Thanks. >> >> >> On Mon, Jun 2, 2014 at 10:52 AM, Isuru Haththotuwa <isu...@apache.org> >> wrote: >> >>> Hi Devs, >>> >>> This is an addition to the discussion happened in the thread [1]. I have >>> included a very basic sequence diagram to show the flow of how Service >>> Grouping would happen for the initial implementation. >>> >>> >>> composite_app_1.png >>> <https://docs.google.com/a/wso2.com/file/d/0B4pCC9A49FwCRDhqQ0JDRl9tQjA/edit?usp=drive_web> >>> >>> Short description of the flow:. >>> >>> 1, 2 & 3. Deploy Components' Definitions that would be included in the >>> top level Composite Application. Typically, a component would map to a >>> single cartridge. For sample JSON definitions of a component, please refer >>> [1]. >>> >>> 4. Deploy a Group Definition, which would logically group the relevant >>> components. This would include information on the Startup Order of each >>> component, and how to handle the termination/error situations as well (Kill >>> Behavior). >>> >>> 5. Deploy a Nested Group Definition, which would contain one/more of >>> Components and Groups. >>> >>> 6. Deploy the Composite Application Definition. This would map to the >>> operation 'Subscription' which we have currently, when spinning up a single >>> cartridge instance. As per the discussion that took place in the above >>> mentioned thread, this was decided to be called the 'Composite >>> Application Definition' deployment, rather than a Subscription. >>> >>> For the initial version, we can restrict this Composite Application >>> Definition only to contain information for each group/component, such as >>> aliases, git repositories and relevant info as required, etc., and not >>> allow further grouping at this level. >>> >>> A typical basic Composite Application Definition, in JSON format, would >>> be as follows: >>> >>> { >>> "name": "group2", >>> "alias": "<group2_alias>", >>> "components": [ >>> { >>> "name": "component2", >>> "alias": "<component2_alias>", >>> "repoUrRL": "<repo_url>" >>> } >>> ], >>> "groups": [ >>> { >>> "name": "group1", >>> "alias": "group1_alias", >>> "components": [ >>> { >>> "name": "component1", >>> "alias": "<component1_alias>", >>> "xxx": "<xxx>" >>> }, >>> { >>> "name": "component3", >>> "alias": "<component3_alias>", >>> "yyy": "<yyy>" >>> } >>> ] >>> } >>> ] >>> } >>> >>> More information is available in the above mentioned mail thread and in >>> [2]. Please share your feedback on this. >>> >>> >>> [1]. [Discuss] Grouping of services (cartridges) >>> [2]. >>> https://docs.google.com/a/wso2.com/document/d/1qnArxF8obhbjMLUbPAENQMn94fPSd3AVqO41mxhnJXE/edit# >>> >> >> >> >> -- >> -- >> Lahiru Sandaruwan >> Committer and PMC member, Apache Stratos, >> Senior Software Engineer, >> WSO2 Inc., http://wso2.com >> lean.enterprise.middleware >> >> email: lahi...@wso2.com cell: (+94) 773 325 954 >> blog: http://lahiruwrites.blogspot.com/ >> twitter: http://twitter.com/lahirus >> linked-in: >> http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146 >> >> -- >> <http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146> >> Thanks and Regards, >> >> Isuru H. >> <http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146> >> +94 716 358 048 <http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146>* >> <http://wso2.com/>* >> >> >> * <http://wso2.com/>* >> >> >> >> -- -- Lahiru Sandaruwan Committer and PMC member, Apache Stratos, Senior Software Engineer, WSO2 Inc., http://wso2.com lean.enterprise.middleware email: lahi...@wso2.com cell: (+94) 773 325 954 blog: http://lahiruwrites.blogspot.com/ twitter: http://twitter.com/lahirus linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
