Hi all, today we (Marcel, Jan-Willem, Jaap & me) had a face-2-face meeting which gave us an opportunity to discuss this matter some more. The conclusion is that we will keep the definition of amdatu.pid as documented on the wiki. In short this comes down to:
1) The tenant.pid is a globally unique identifier. Thus even in a distributed setup each TenantService will have a unique identifier used by the Multi-Tenant host environment. Applications should not use or depend on this identifier in any way. 2) When an Application needs a way to associate multiple instances in any way it should preferably use configuration (eg. ConfigurationAdmin). In special cases (deployment models) custom configuration can also be added directly to the TenantService properties. We feel this should be sufficient to cover the cases I mentioned in earlier posts. 3) In answer to Ivo's original question about detecting if a TenantService gets deleted/removed not just deregistered from the service registry. Yes you can, BUT only under the definition at 1 and thus within one single container. I imagine this does not easily/fully cover your clustered cassandra use-case if you whish to support dynamicly changing deployment topology (scale up/down). This is not new, cause the old model didn't either. Multi-Tenancy and Provisioning simply do not have a concept of clustering. We will need to explore these orchestration/communication use cases further when we get to Service Fabric. I hope this clear things up after a lengthy discussion :) We are in agreement on this, but if you have any comments or additional question don't hold back! Thanks & Regards, Bram On Tue, Jan 31, 2012 at 1:22 PM, Bram de Kruijff <[email protected]> wrote: > Hi Jan-Willem > > On Tue, Jan 31, 2012 at 11:39 AM, Jan Willem Janssen > <[email protected]> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 1/31/12 11:07 AM, Bram de Kruijff wrote: >>> Hi all, >>> >>> 2012/1/30 Marcel Offermans <[email protected]>: >>>> >>>> Some of us (including me) see a tenant as a logical entity that >>>> (possibly) spans multiple nodes. So one can say "Tenant X is >>>> deployed to nodes A, B, C". This allows applications (eg. Amdatu >>>> Big Data) to use the tenant.pid as an identifying key when >>>> creating a keyspace for Tenant X. This strategy is something we >>>> will discourage in 1.0 but that is besides the point for now. >>>> >>>> >>>> After a voice conference on Skype, Bram, Jan Willem and I just >>>> agreed that the tenant.pid is globally unique and only of >>>> interest to the Amdatu Platform and therefore cannot be used as >>>> an identifying key of a storage mechanism of an application (see >>>> the footnote below, or click >>>> http://www.amdatu.org/confluence/display/Amdatu/Amdatu+Core+Tenant+Design >>>> if you don't want to scroll down (the yellow box is our summary >>>> of this discussion)). Applications should use their own >>>> configuration to configure the name of (in this case) a >>>> keyspace. >>> >>> I'm just gonna go on record here. I send my reply on this thread >>> after that call and said: >>> >>>> On Jan 30, 2012, at 12:51 , Bram de Kruijff wrote: >>>> >>>> Although the discussion about the exact meaning op tenant.pid not >>>> yet finalized entirely it is very important to realize what >>>> interpretation is being used by whom when they reply. So I >>>> propose to explicitly mention whether you are talking about local >>>> or distributed events. >>> >>> IMHO it is not finalized and there more I think about it I tend to >>> disagree. I did agree to the fact stated by Jan-Willem that >>> applications should not use it as on identifier but rather prefer >>> their own configuration space. >>> >>> My concerns from two are two angels: >>> >>> 1) Why the tenant.pid should be globally unique? >>> >>> [snip] >>> >>> 2) Why the tenant.pid should NOT be globally unique? >>> >>> [snip] >>> >>> Bottomline, I do not believe we need a logical globally unique >>> identifier. At least you have not shown me a concrete use case for >>> it that can not be easily solved in another way. We may need a >>> (generated) system identifier but we should not hijack and remove >>> a higher level concept. >> >> We do agree on these two things: >> 1) the tenant.pid should have *no* meaning whatsoever; > > ... to the application. It should not depend on it or use it as a key. > >> 2) the tenant.pid should be specified upfront. > > ... probably if you want to send it as config. The application doesn't care. > >> If we would say, as developers of a platform, that the tenant.pid >> should be globally unique, it always gives you the advantage that this >> property will be unique in *any* form of application that is built on >> top of Amdatu. > > 1) Give me a concrete platform use case. Application developers can't use it. > 2) The need for a unique identifier does not imply that tenant.pid must be it. > >> Additionally, making the tenant.pid really non-informative by making >> it, for example, a GUID ensures that this property really stays >> meaningless. > > I agree that a unique identifier should be generated. It is a system > id. Not something users care about. > >> If a user of the Amdatu platform decides otherwise, he should also >> deal with any problems that might occur. At least the platform >> shouldn't be bothered by that... > > A user (application manager / system operator / etc) can't deal with > it. He just thinks in logical constructs. > > Thinking about this I think we may come to a middle ground by > reintroducing tenant.id. > > tenant.id := Logical identifier of a tenant (eg. "customerX"). Unique per > node > tenant.pid := System identifier of a tenant process (eg. > "8237490832704hu-032uf2309"). Unique over all nodes > > grz > Bram _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
