On Mon, Jul 7, 2014 at 8:05 AM, Udara Liyanage <ud...@wso2.com> wrote:
> HI Lahiru, > > As I understood, SM sends the details to the CC via service call or event > based, then CC update the topology and publish topology events. > If so, Autoscaler does not need to get any information from the event published by SM. Then service call is better IMO. Thanks. > > > On Mon, Jul 7, 2014 at 6:09 PM, Lahiru Sandaruwan <lahi...@wso2.com> > wrote: > >> >> >> >> 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 >> >> > > > -- > > Udara Liyanage > Software Engineer > WSO2, Inc.: http://wso2.com > lean. enterprise. middleware > > web: http://udaraliyanage.wordpress.com > phone: +94 71 443 6897 > -- -- 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
