Hi Imesh, It seems my single tenant app[1] is failing. Do i need to change it?
Error is at [2]. Thanks. [1] https://github.com/rekathiru/grouping-samples/tree/master/dependency_scaling/sample_groups [2] [2015-01-09 23:33:27,758] INFO {org.apache.stratos.autoscaler.services.impl.AutoScalerServiceImpl} - Adding application signup: [application-id] app_group_v2 [2015-01-09 23:33:27,773] INFO {org.apache.stratos.manager.components.ApplicationSignUpHandler} - Adding application signup: [application-id] app_group_v2 [tenant-id] -1234 [2015-01-09 23:33:27,774] ERROR {org.apache.stratos.manager.components.ApplicationSignUpHandler} - Could not add application signup java.lang.RuntimeException: Application not found: [application-id] app_group_v2 at org.apache.stratos.manager.components.ApplicationSignUpHandler.addApplicationSignUp(ApplicationSignUpHandler.java:72) at org.apache.stratos.manager.services.impl.StratosManagerServiceImpl.addApplicationSignUp(StratosManagerServiceImpl.java:55) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:212) at org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:117) at org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40) at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:110) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180) On Wed, Jan 7, 2015 at 3:33 PM, Imesh Gunaratne <[email protected]> wrote: > Hi Devs, > > I have now completed Application SignUp functionality for Multi-Tenant > applications and pushed changes to master branch. > > This is how it works: > - There is no application signup support for single-tenant applications, > it's only available for multi-tenant applications. > - For single-tenant applications Autoscaler will create an applicaiton > signup internally but it will not be visible via the API. > - An application sign up may contain a list of artifact repositories: > > { > "applicationId":"single-cartridge-app", > "artifactRepositories":[ > { > "alias":"php", > "privateRepo":false, > "repoUrl":"https://github.com/imesh/stratos-php-applications.git > ", > "repoUsername":"", > "repoPassword":"" > }, > { > "alias":"tomcat", > "privateRepo":false, > "repoUrl":" > https://github.com/imesh/stratos-tomcat-applications.git", > "repoUsername":"", > "repoPassword":"" > } > ] > } > > - Following API methods are introduced to manage application signups: > POST /applications/{applicationId}/signups > GET /applications/{applicationId}/signups/{signUpId} > GET /applications/{applicationId}/signups/ > DELETE /applications/{applicationId}/signups/{signUpId} > > Thanks > > On Tue, Jan 6, 2015 at 7:45 PM, Imesh Gunaratne <[email protected]> wrote: > >> I have now completed the initial version of Application SignUp support >> for multi-tenant applications. Changes were pushed to master branch. Now >> I'm working on fixing the logic which notify ADC to send Artifact Update >> event on Git updates. >> >> Please find latest sample artifacts here: >> https://github.com/imesh/stratos-samples.git >> >> Thanks >> >> On Mon, Jan 5, 2015 at 12:32 PM, Lakmal Warusawithana <[email protected]> >> wrote: >> >>> Thing is all other sunscribleInfo used in AS and only repo info used in >>> SM. In the single tenant, all these come to AS when deploying the >>> application and we need to pass subscribleInfo to SM for ADC usage. MT >>> scenario subscribleInfo comes to SM. If consider all scenario, IMO this is >>> a good move. >>> >>> On Mon, Jan 5, 2015 at 12:24 PM, Sajith Kariyawasam <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Mon, Jan 5, 2015 at 12:13 PM, Imesh Gunaratne <[email protected]> >>>> wrote: >>>> >>>>> Following is the current definition of Subscribable Info in an >>>>> application: >>>>> >>>>> { >>>>> "applicationId":"single-cartridge-app", >>>>> "alias":"single-cartridge-app", >>>>> "components":{ >>>>> "cartridges":[ >>>>> { >>>>> "type":"php", >>>>> "cartridgeMin":1, >>>>> "cartridgeMax":10, >>>>> "*subscribableInfo*":{ >>>>> "alias":"php", >>>>> "autoscalingPolicy":"autoscale-policy-1", >>>>> "privateRepo":false, >>>>> "repoUrl":" >>>>> https://github.com/imesh/stratos-php-applications.git", >>>>> "repoUsername":"", >>>>> "repoPassword":"" >>>>> } >>>>> } >>>>> ] >>>>> } >>>>> } >>>>> >>>>> Here I think we can move artifact repository information to an inner >>>>> block within Subscribable Info as follows since we need to store it >>>>> separately in SM, please add your thoughts: >>>>> >>>>> { >>>>> "applicationId":"single-cartridge-app", >>>>> "alias":"single-cartridge-app", >>>>> "components":{ >>>>> "cartridges":[ >>>>> { >>>>> "type":"php", >>>>> "cartridgeMin":1, >>>>> "cartridgeMax":10, >>>>> "*subscribableInfo*":{ >>>>> "alias":"php", >>>>> "autoscalingPolicy":"autoscale-policy-1", >>>>> "*artifactRepository*":{ >>>>> "privateRepo":false, >>>>> "repoUrl":" >>>>> https://github.com/imesh/stratos-php-applications.git", >>>>> "repoUsername":"", >>>>> "repoPassword":"" >>>>> } >>>>> } >>>>> } >>>>> ] >>>>> } >>>>> } >>>>> >>>> >>>> Imesh, >>>> >>>> Can't we just store the subscribableInfo object with the repo >>>> information? I can't clearly see any advantage of moving it to a separate >>>> object, besides this will result a change of Domain Objects / API s? >>>> >>>> >>>>> >>>>> Thanks >>>>> >>>>> On Mon, Jan 5, 2015 at 11:50 AM, Imesh Gunaratne <[email protected]> >>>>> wrote: >>>>> >>>>>> +1 for the design Lakmal! >>>>>> >>>>>> Will store subscribable information in SM and expose a service to >>>>>> manage them. For single tenant applications will make a call from >>>>>> Autoscaler to SM to register subscribable information. For Multi-Tenant >>>>>> applications will expose a REST API method to signup. >>>>>> >>>>>> Thanks >>>>>> >>>>>> On Mon, Jan 5, 2015 at 11:45 AM, Lakmal Warusawithana < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> IMO we can handle it without major refactor. We can have property in >>>>>>> application to define whether single tenant or MT. MT applications are >>>>>>> only >>>>>>> create and deploy by Super tenant. If MT application deployed, we can >>>>>>> expose a API, to get subscribe info when signup to the MT application by >>>>>>> tenant. >>>>>>> >>>>>>> Further, we should store all subscribe info in SM. To generalize the >>>>>>> process, for the single tenant, we should call internal signup call with >>>>>>> subscribe info and store them in SM. Then we have single place store all >>>>>>> subscribe info and ADC can use it for artifact distribution. >>>>>>> >>>>>>> On Sun, Jan 4, 2015 at 5:43 PM, Imesh Gunaratne <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Devs, >>>>>>>> >>>>>>>> At present with service grouping functionality an application can >>>>>>>> have only one subscription. This subscription may include multiple >>>>>>>> subscribable information blocks for multiple cartridges. >>>>>>>> >>>>>>>> To support Multi-Tenant applications which may include Multi-Tenant >>>>>>>> cartridges we should be able to manage multiple subscriptions for each >>>>>>>> cartridge. Currently we do not have a concept of subscribing to >>>>>>>> applications. >>>>>>>> >>>>>>>> Shall we introduce a new artifact called Application Subscription >>>>>>>> and move subscribable information blocks from Application definition >>>>>>>> to it? >>>>>>>> >>>>>>>> Then the workflow may change as follows: >>>>>>>> - Add autoscaling policy >>>>>>>> - Add cartridges >>>>>>>> - Add groups >>>>>>>> - Add application >>>>>>>> - Deploy application >>>>>>>> - Subscribe to application: >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Imesh Gunaratne >>>>>>>> >>>>>>>> Technical Lead, WSO2 >>>>>>>> Committer & PMC Member, Apache Stratos >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Lakmal Warusawithana >>>>>>> Vice President, Apache Stratos >>>>>>> Director - Cloud Architecture; WSO2 Inc. >>>>>>> Mobile : +94714289692 >>>>>>> Blog : http://lakmalsview.blogspot.com/ >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Imesh Gunaratne >>>>>> >>>>>> Technical Lead, WSO2 >>>>>> Committer & PMC Member, Apache Stratos >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Imesh Gunaratne >>>>> >>>>> Technical Lead, WSO2 >>>>> Committer & PMC Member, Apache Stratos >>>>> >>>> >>>> >>>> >>>> -- >>>> *Sajith Kariyawasam* >>>> >>>> *Committer and PMC member, Apache Stratos,WSO2 Inc., http://wso2.com >>>> <http://wso2.com>AMIE (SL)Mobile: +94772269575* >>>> >>> >>> >>> >>> -- >>> Lakmal Warusawithana >>> Vice President, Apache Stratos >>> Director - Cloud Architecture; WSO2 Inc. >>> Mobile : +94714289692 >>> Blog : http://lakmalsview.blogspot.com/ >>> >>> >> >> >> -- >> Imesh Gunaratne >> >> Technical Lead, WSO2 >> Committer & PMC Member, Apache Stratos >> > > > > -- > Imesh Gunaratne > > Technical Lead, WSO2 > Committer & PMC Member, Apache Stratos > -- -- Lahiru Sandaruwan Committer and PMC member, Apache Stratos, Senior Software Engineer, WSO2 Inc., http://wso2.com lean.enterprise.middleware email: [email protected] blog: http://lahiruwrites.blogspot.com/ linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
