I have now completed the initial version of Application SignUp support for multi-tenant applications. Changes were pushed to master branch. Now I'm working on fixing the logic which notify ADC to send Artifact Update event on Git updates.
Please find latest sample artifacts here: https://github.com/imesh/stratos-samples.git Thanks On Mon, Jan 5, 2015 at 12:32 PM, Lakmal Warusawithana <[email protected]> wrote: > Thing is all other sunscribleInfo used in AS and only repo info used in > SM. In the single tenant, all these come to AS when deploying the > application and we need to pass subscribleInfo to SM for ADC usage. MT > scenario subscribleInfo comes to SM. If consider all scenario, IMO this is > a good move. > > On Mon, Jan 5, 2015 at 12:24 PM, Sajith Kariyawasam <[email protected]> > wrote: > >> >> >> On Mon, Jan 5, 2015 at 12:13 PM, Imesh Gunaratne <[email protected]> >> wrote: >> >>> Following is the current definition of Subscribable Info in an >>> application: >>> >>> { >>> "applicationId":"single-cartridge-app", >>> "alias":"single-cartridge-app", >>> "components":{ >>> "cartridges":[ >>> { >>> "type":"php", >>> "cartridgeMin":1, >>> "cartridgeMax":10, >>> "*subscribableInfo*":{ >>> "alias":"php", >>> "autoscalingPolicy":"autoscale-policy-1", >>> "privateRepo":false, >>> "repoUrl":" >>> https://github.com/imesh/stratos-php-applications.git";, >>> "repoUsername":"", >>> "repoPassword":"" >>> } >>> } >>> ] >>> } >>> } >>> >>> Here I think we can move artifact repository information to an inner >>> block within Subscribable Info as follows since we need to store it >>> separately in SM, please add your thoughts: >>> >>> { >>> "applicationId":"single-cartridge-app", >>> "alias":"single-cartridge-app", >>> "components":{ >>> "cartridges":[ >>> { >>> "type":"php", >>> "cartridgeMin":1, >>> "cartridgeMax":10, >>> "*subscribableInfo*":{ >>> "alias":"php", >>> "autoscalingPolicy":"autoscale-policy-1", >>> "*artifactRepository*":{ >>> "privateRepo":false, >>> "repoUrl":" >>> https://github.com/imesh/stratos-php-applications.git";, >>> "repoUsername":"", >>> "repoPassword":"" >>> } >>> } >>> } >>> ] >>> } >>> } >>> >> >> Imesh, >> >> Can't we just store the subscribableInfo object with the repo >> information? I can't clearly see any advantage of moving it to a separate >> object, besides this will result a change of Domain Objects / API s? >> >> >>> >>> Thanks >>> >>> On Mon, Jan 5, 2015 at 11:50 AM, Imesh Gunaratne <[email protected]> >>> wrote: >>> >>>> +1 for the design Lakmal! >>>> >>>> Will store subscribable information in SM and expose a service to >>>> manage them. For single tenant applications will make a call from >>>> Autoscaler to SM to register subscribable information. For Multi-Tenant >>>> applications will expose a REST API method to signup. >>>> >>>> Thanks >>>> >>>> On Mon, Jan 5, 2015 at 11:45 AM, Lakmal Warusawithana <[email protected]> >>>> wrote: >>>> >>>>> IMO we can handle it without major refactor. We can have property in >>>>> application to define whether single tenant or MT. MT applications are >>>>> only >>>>> create and deploy by Super tenant. If MT application deployed, we can >>>>> expose a API, to get subscribe info when signup to the MT application by >>>>> tenant. >>>>> >>>>> Further, we should store all subscribe info in SM. To generalize the >>>>> process, for the single tenant, we should call internal signup call with >>>>> subscribe info and store them in SM. Then we have single place store all >>>>> subscribe info and ADC can use it for artifact distribution. >>>>> >>>>> On Sun, Jan 4, 2015 at 5:43 PM, Imesh Gunaratne <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Devs, >>>>>> >>>>>> At present with service grouping functionality an application can >>>>>> have only one subscription. This subscription may include multiple >>>>>> subscribable information blocks for multiple cartridges. >>>>>> >>>>>> To support Multi-Tenant applications which may include Multi-Tenant >>>>>> cartridges we should be able to manage multiple subscriptions for each >>>>>> cartridge. Currently we do not have a concept of subscribing to >>>>>> applications. >>>>>> >>>>>> Shall we introduce a new artifact called Application Subscription and >>>>>> move subscribable information blocks from Application definition to it? >>>>>> >>>>>> Then the workflow may change as follows: >>>>>> - Add autoscaling policy >>>>>> - Add cartridges >>>>>> - Add groups >>>>>> - Add application >>>>>> - Deploy application >>>>>> - Subscribe to application: >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> -- >>>>>> Imesh Gunaratne >>>>>> >>>>>> Technical Lead, WSO2 >>>>>> Committer & PMC Member, Apache Stratos >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Lakmal Warusawithana >>>>> Vice President, Apache Stratos >>>>> Director - Cloud Architecture; WSO2 Inc. >>>>> Mobile : +94714289692 >>>>> Blog : http://lakmalsview.blogspot.com/ >>>>> >>>>> >>>> >>>> >>>> -- >>>> Imesh Gunaratne >>>> >>>> Technical Lead, WSO2 >>>> Committer & PMC Member, Apache Stratos >>>> >>> >>> >>> >>> -- >>> Imesh Gunaratne >>> >>> Technical Lead, WSO2 >>> Committer & PMC Member, Apache Stratos >>> >> >> >> >> -- >> *Sajith Kariyawasam* >> >> *Committer and PMC member, Apache Stratos,WSO2 Inc., http://wso2.com >> <http://wso2.com>AMIE (SL)Mobile: +94772269575* >> > > > > -- > Lakmal Warusawithana > Vice President, Apache Stratos > Director - Cloud Architecture; WSO2 Inc. > Mobile : +94714289692 > Blog : http://lakmalsview.blogspot.com/ > > -- Imesh Gunaratne Technical Lead, WSO2 Committer & PMC Member, Apache Stratos
