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 <lak...@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 <saj...@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 <lak...@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

Reply via email to