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 <[email protected]> wrote:

> +1 for the design Lakmal!
>
> Will store subscribable information in SM and expose a service to manage
> them. For single tenant applications will make a call from Autoscaler to SM
> to register subscribable information. For Multi-Tenant applications will
> expose a REST API method to signup.
>
> Thanks
>
> On Mon, Jan 5, 2015 at 11:45 AM, Lakmal Warusawithana <[email protected]>
> wrote:
>
>> IMO we can handle it without major refactor. We can have property in
>> application to define whether single tenant or MT. MT applications are only
>> create and deploy by Super tenant. If MT application deployed, we can
>> expose a API, to get subscribe info when signup to the MT application by
>> tenant.
>>
>> Further, we should store all subscribe info in SM. To generalize the
>> process, for the single tenant, we should call internal signup call with
>> subscribe info and store them in SM. Then we have single place store all
>> subscribe info and ADC can use it for artifact distribution.
>>
>> On Sun, Jan 4, 2015 at 5:43 PM, Imesh Gunaratne <[email protected]> wrote:
>>
>>> Hi Devs,
>>>
>>> At present with service grouping functionality an application can have
>>> only one subscription. This subscription may include multiple subscribable
>>> information blocks for multiple cartridges.
>>>
>>> To support Multi-Tenant applications which may include Multi-Tenant
>>> cartridges we should be able to manage multiple subscriptions for each
>>> cartridge. Currently we do not have a concept of subscribing to
>>> applications.
>>>
>>> Shall we introduce a new artifact called Application Subscription and
>>> move subscribable information blocks from Application definition to it?
>>>
>>> Then the workflow may change as follows:
>>> - Add autoscaling policy
>>> - Add cartridges
>>> - Add groups
>>> - Add application
>>> - Deploy application
>>> - Subscribe to application:
>>>
>>> Thanks
>>>
>>>
>>> --
>>> Imesh Gunaratne
>>>
>>> Technical Lead, WSO2
>>> Committer & PMC Member, Apache Stratos
>>>
>>
>>
>>
>> --
>> Lakmal Warusawithana
>> Vice President, Apache Stratos
>> Director - Cloud Architecture; WSO2 Inc.
>> Mobile : +94714289692
>> Blog : http://lakmalsview.blogspot.com/
>>
>>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>



-- 
Imesh Gunaratne

Technical Lead, WSO2
Committer & PMC Member, Apache Stratos

Reply via email to