You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Imesh Gunaratne <im...@apache.org> on 2015/01/04 13:13:58 UTC
[Discuss] Multi-Tenancy Support for Applications
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
Re: [Discuss] Multi-Tenancy Support for Applications
Posted by Imesh Gunaratne <im...@apache.org>.
I have now fixed this issue by moving artifact repository password
encryption logic to stratos manager service clients. Application key was
needed by this logic hence application was read.
Please take a pull and build again.
Thanks
On Sat, Jan 10, 2015 at 10:12 PM, Imesh Gunaratne <im...@apache.org> wrote:
> As I found this problem occurs as follows:
> - When an application is deployed, Autoscaler publishes Application
> Created event.
> - Soon after Autoscaler makes a call to Stratos Manager to add an
> Application SignUp.
> - At this point Stratos Manager has not received the Application Created
> event.
> - As a result it throws application not found exception.
>
> Seems like event processing is much slower than a service call. Might need
> to review this flow and change the logic.
>
> Thanks
>
> On Sat, Jan 10, 2015 at 12:00 AM, Lahiru Sandaruwan <la...@wso2.com>
> wrote:
>
>> Thanks Imesh.
>>
>> On Fri, Jan 9, 2015 at 11:52 PM, Imesh Gunaratne <im...@apache.org>
>> wrote:
>>
>>> Hi Lahiru,
>>>
>>> No, there shouldn't be any impact on single-tenant applications from the
>>> above implementation. Will investigate and see what's causing this.
>>>
>>> Thanks
>>>
>>> On Fri, Jan 9, 2015 at 11:47 PM, Lahiru Sandaruwan <la...@wso2.com>
>>> wrote:
>>>
>>>> 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 <im...@apache.org>
>>>> 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 <im...@apache.org>
>>>>> 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 <
>>>>>> lakmal@wso2.com> 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 <sajith@wso2.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jan 5, 2015 at 12:13 PM, Imesh Gunaratne <im...@apache.org>
>>>>>>>> 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 <imesh@apache.org
>>>>>>>>> > 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 <
>>>>>>>>>> lakmal@wso2.com> 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 <
>>>>>>>>>>> imesh@apache.org> 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: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
>>>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>>>
>>>>
>>>
>>>
>>> --
>>> 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: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>
>>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: [Discuss] Multi-Tenancy Support for Applications
Posted by Imesh Gunaratne <im...@apache.org>.
As I found this problem occurs as follows:
- When an application is deployed, Autoscaler publishes Application Created
event.
- Soon after Autoscaler makes a call to Stratos Manager to add an
Application SignUp.
- At this point Stratos Manager has not received the Application Created
event.
- As a result it throws application not found exception.
Seems like event processing is much slower than a service call. Might need
to review this flow and change the logic.
Thanks
On Sat, Jan 10, 2015 at 12:00 AM, Lahiru Sandaruwan <la...@wso2.com>
wrote:
> Thanks Imesh.
>
> On Fri, Jan 9, 2015 at 11:52 PM, Imesh Gunaratne <im...@apache.org> wrote:
>
>> Hi Lahiru,
>>
>> No, there shouldn't be any impact on single-tenant applications from the
>> above implementation. Will investigate and see what's causing this.
>>
>> Thanks
>>
>> On Fri, Jan 9, 2015 at 11:47 PM, Lahiru Sandaruwan <la...@wso2.com>
>> wrote:
>>
>>> 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 <im...@apache.org>
>>> 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 <im...@apache.org>
>>>> 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 <lakmal@wso2.com
>>>>> > 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 <sa...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jan 5, 2015 at 12:13 PM, Imesh Gunaratne <im...@apache.org>
>>>>>>> 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 <im...@apache.org>
>>>>>>>> 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 <
>>>>>>>>> lakmal@wso2.com> 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 <imesh@apache.org
>>>>>>>>>> > 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: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
>>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>>
>>>
>>
>>
>> --
>> 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: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: [Discuss] Multi-Tenancy Support for Applications
Posted by Lahiru Sandaruwan <la...@wso2.com>.
Thanks Imesh.
On Fri, Jan 9, 2015 at 11:52 PM, Imesh Gunaratne <im...@apache.org> wrote:
> Hi Lahiru,
>
> No, there shouldn't be any impact on single-tenant applications from the
> above implementation. Will investigate and see what's causing this.
>
> Thanks
>
> On Fri, Jan 9, 2015 at 11:47 PM, Lahiru Sandaruwan <la...@wso2.com>
> wrote:
>
>> 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 <im...@apache.org> 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 <im...@apache.org>
>>> 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 <la...@wso2.com>
>>>> 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 <sa...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 5, 2015 at 12:13 PM, Imesh Gunaratne <im...@apache.org>
>>>>>> 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 <im...@apache.org>
>>>>>>> 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 <
>>>>>>>> lakmal@wso2.com> 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 <im...@apache.org>
>>>>>>>>> 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: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>
>>
>
>
> --
> 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: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
Re: [Discuss] Multi-Tenancy Support for Applications
Posted by Imesh Gunaratne <im...@apache.org>.
Hi Lahiru,
No, there shouldn't be any impact on single-tenant applications from the
above implementation. Will investigate and see what's causing this.
Thanks
On Fri, Jan 9, 2015 at 11:47 PM, Lahiru Sandaruwan <la...@wso2.com> wrote:
> 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 <im...@apache.org> 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 <im...@apache.org> 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 <la...@wso2.com>
>>> 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 <sa...@wso2.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 5, 2015 at 12:13 PM, Imesh Gunaratne <im...@apache.org>
>>>>> 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 <im...@apache.org>
>>>>>> 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 <
>>>>>>> lakmal@wso2.com> 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 <im...@apache.org>
>>>>>>>> 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: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: [Discuss] Multi-Tenancy Support for Applications
Posted by Lahiru Sandaruwan <la...@wso2.com>.
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 <im...@apache.org> 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 <im...@apache.org> 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 <la...@wso2.com>
>> 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 <sa...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jan 5, 2015 at 12:13 PM, Imesh Gunaratne <im...@apache.org>
>>>> 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 <im...@apache.org>
>>>>> 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 <
>>>>>> lakmal@wso2.com> 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 <im...@apache.org>
>>>>>>> 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: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
Re: [Discuss] Multi-Tenancy Support for Applications
Posted by Imesh Gunaratne <im...@apache.org>.
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 <im...@apache.org> 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 <la...@wso2.com>
> 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 <sa...@wso2.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, Jan 5, 2015 at 12:13 PM, Imesh Gunaratne <im...@apache.org>
>>> 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 <im...@apache.org>
>>>> 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 <lakmal@wso2.com
>>>>> > 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 <im...@apache.org>
>>>>>> 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
Re: [Discuss] Multi-Tenancy Support for Applications
Posted by Imesh Gunaratne <im...@apache.org>.
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 <la...@wso2.com>
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 <sa...@wso2.com>
> wrote:
>
>>
>>
>> On Mon, Jan 5, 2015 at 12:13 PM, Imesh Gunaratne <im...@apache.org>
>> 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 <im...@apache.org>
>>> 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 <la...@wso2.com>
>>>> 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 <im...@apache.org>
>>>>> 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
Re: [Discuss] Multi-Tenancy Support for Applications
Posted by Lakmal Warusawithana <la...@wso2.com>.
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 <sa...@wso2.com> wrote:
>
>
> On Mon, Jan 5, 2015 at 12:13 PM, Imesh Gunaratne <im...@apache.org> 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 <im...@apache.org>
>> 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 <la...@wso2.com>
>>> 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 <im...@apache.org>
>>>> 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/
Re: [Discuss] Multi-Tenancy Support for Applications
Posted by Sajith Kariyawasam <sa...@wso2.com>.
On Mon, Jan 5, 2015 at 12:13 PM, Imesh Gunaratne <im...@apache.org> 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 <im...@apache.org> 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 <la...@wso2.com>
>> 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 <im...@apache.org>
>>> 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*
Re: [Discuss] Multi-Tenancy Support for Applications
Posted by Imesh Gunaratne <im...@apache.org>.
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":""
}
}
}
]
}
}
Thanks
On Mon, Jan 5, 2015 at 11:50 AM, Imesh Gunaratne <im...@apache.org> 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 <la...@wso2.com>
> 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 <im...@apache.org> 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
Re: [Discuss] Multi-Tenancy Support for Applications
Posted by Imesh Gunaratne <im...@apache.org>.
+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 <la...@wso2.com>
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 <im...@apache.org> 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
Re: [Discuss] Multi-Tenancy Support for Applications
Posted by Lakmal Warusawithana <la...@wso2.com>.
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 <im...@apache.org> 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/