Imesh, Tenant ID is an internal thing that is used in Carbon and it's not exposed to outside. You would realize this if you have a look at the tenant creation UI.
IMO we shouldn't complicate things unnecessarily. I'm a great fan of generic code, but it should be applied carefully. All, We first need to identify which parts of this would depend on different-different implementations and which parts are independent. Identifying a tenant from a request url can be different from platform to platform. Hence, IMO, that's where we need an abstract definition. And the thinnest bit of requirement of LB would be 'I will provide you the request I received, let me know from which tenant this request came from'. And initially we could only have an implementation for Carbon Multi-tenant platform. This design should also follow 'chain of responsibility design pattern' IMO, where for a given request, only one tenant extraction implementation will be used. This way we do not need to come up with imaginary URL patterns which might never even get used. WDYT? On Sun, Oct 27, 2013 at 11:50 AM, Imesh Gunaratne <[email protected]> wrote: > Hi Kishanthan, > > Thanks for your feedback. > > Yes exactly that is the idea. We are trying to provide a generic > implementation for Multi-Tenancy support. Yes tenant domain would be more > meaningful than the tenant id to be used in the URL. However IMO we could > support both. > > Thanks > Imesh > > > > On Sun, Oct 27, 2013 at 10:18 AM, Kishanthan Thangarajah < > [email protected]> wrote: > >> >> >> >> On Thu, Oct 24, 2013 at 3:16 PM, Imesh Gunaratne <[email protected]>wrote: >> >>> Hi, >>> >>> Today we had an offline discussion on Multi-Tenancy support in Apache >>> Stratos (incubating) version 4.0.0 with Lakmal and Reka. Please find the >>> summary of the discussion below. >>> >>> *Background* >>> - Multi-tenant cartridges could be partitioned into clusters by defining >>> tenant ranges for each cluster. >>> Example: (Cluster 1 - Tenant Range: 1-100, Cluster 2 - Tenant Range: >>> 101-200, Cluster 3: Tenant Range: 201-*) >>> - Each tenant needs to define an id and a domain name. >>> >>> *The Challenges* >>> C1. One of the major challenges when implementing Multi-Tenancy support >>> in a PaaS is that having a common mechanism to identify the tenant from the >>> incoming request. Different applications could use different approaches. >>> C2. The next challenge in Stratos is that sending tenant information >>> (tenant id and tenant domain name of a given subscription) from Stratos >>> Manager to Load Balancers. >>> >>> *The Proposal for C1* >>> The idea is to identify the tenant either using tenant id or tenant >>> domain name. Here the tenant domain name represents the domain name used to >>> subscribe to a Multi-Tenant cartridge. The following templates illustrates >>> how an application could send tenant identifier in an URL. >>> >>> *Template using Tenant ID:* >>> <protocol>://<host-name>:<port>/<path>?<tenant-id-identifier>=<value> >>> Example: >>> http://subscription1.appserver.cloud-provider.org:8280/login?tenantId=1 >>> >>> *Template using Tenant Domain Name:* >>> <protocol>://<host-name>:<port>/<path>?<tenant-domain-identifier>=<value> >>> Example: >>> >>> http://subscription1.appserver.cloud-provider.org:8280/login?tenantDomain=foo.org >>> >> >> From LB point of view, we can use both of the above. >> But from a user perspective (user friendliness), isn't it better to go >> with tenant domain as the identifier? >> >> >>> >>> >>> In the above examples the tenant id and tenant domain name identifiers >>> are defined as "tenantId" and "tenantDomain". However we could make this >>> configurable, so that those could be changed for a given Stratos >>> environment or Multi-Tenant cartridge. >>> >>> *The Proposal for C2:* >>> Currently load balancers receive this information using a common >>> database which I think is not a scalable option. >>> Tenant information could be published to a message broker topic and the >>> load balancers could subscribe to this topic to retrieve the information. >>> Using this approach we could preserve the loosely coupled nature of the >>> load balancer. >>> >>> Please feel free to add your thoughts. >>> >>> Many Thanks >>> Imesh >>> >> >> > -- Best Regards, Nirmal Nirmal Fernando. PPMC Member & Committer of Apache Stratos, Senior Software Engineer, WSO2 Inc. Blog: http://nirmalfdo.blogspot.com/
