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